* Reproducible Research Hackathon: Friday, July 3rd @ 2020-06-30 12:40 simon tournier 2020-07-01 4:57 ` Pjotr Prins 2020-07-03 17:10 ` zimoun 0 siblings, 2 replies; 17+ messages in thread From: simon tournier @ 2020-06-30 12:40 UTC (permalink / raw) To: guix-devel, guix-hpc Hello, We are pleased to announce a Hackathon about Reproducible Science. We propose to collectively tackle some issues on *Friday, July 3rd*: - identify stumbling blocks in using Guix to write end-to-end pipelines, - document how to achieve this, - feed the Guix-Past channel by other old packages, - provide guix.scm for some of the ReScience C submissions. Feel free to contact us at guix-hpc@gnu.org if you would like to hack with us. We will meet at *9:30 CEST* on the #guix-hpc channel of irc.freenode.net. You can use this web client to reach us: http://guix.gnu.org/contact/irc/ (tweaking the channel name). Read more details at: https://hpc.guix.info/blog/2020/06/reproducible-research-hackathon Hope to see you on Friday. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-06-30 12:40 Reproducible Research Hackathon: Friday, July 3rd simon tournier @ 2020-07-01 4:57 ` Pjotr Prins 2020-07-01 9:10 ` zimoun 2020-07-03 17:10 ` zimoun 1 sibling, 1 reply; 17+ messages in thread From: Pjotr Prins @ 2020-07-01 4:57 UTC (permalink / raw) To: simon tournier; +Cc: guix-devel, guix-hpc We at UTHSC are game. We are struggling with an old version of the GeneNetwork web service 1.x which is now running on a 10 year old CentOS. The backup time machine server died recently. GenNetwork1 depends on Python 2.4(!) with modules that have not been updated this century, and an older version of Apache with mod_python, amongst other things. We would like to use the guix time-machine feature to run older versions on demand in containers, also for the recent GeneNetwork2 version which runs on a modern Guix stack. When we get it to work I would like to push the older packages in Guix-Past. Bit much for one day, but let's see where it ends. There is no point in updating the older GeneNetwork1 instances, I mean the code. The point really is that it is a reproducible version tied to older scientific publications that people still can explore. Note that GeneNetwork requires a largisch MySQL/MariaDB (170GB) which is also a snapshot in time. We have 5+ snapshots of that database that go with 5+ versions of the code. We want to run them all under Guix so we no longer have to care about the underlying Linux distro. With the newer GeneNetwork2 stack we are thinking of making use of Guix timemachine to run snapshots, firing containers up on demand. These will have to be tied with a certain version of the database, so we have to force time points maintained outside the package Guix git repo. The databases can be ready to run - listening on a different port for each version. Nice challenge and it will make a great story when it works. Pj. On Tue, Jun 30, 2020 at 02:40:12PM +0200, simon tournier wrote: > Hello, > > We are pleased to announce a Hackathon about Reproducible Science. > > We propose to collectively tackle some issues on *Friday, July 3rd*: > > - identify stumbling blocks in using Guix to write end-to-end > pipelines, > - document how to achieve this, > - feed the Guix-Past channel by other old packages, > - provide guix.scm for some of the ReScience C submissions. > > Feel free to contact us at guix-hpc@gnu.org if you would like to hack > with us. > > We will meet at *9:30 CEST* on the #guix-hpc channel of > irc.freenode.net. You can use this web client to reach us: > > http://guix.gnu.org/contact/irc/ > > (tweaking the channel name). > > Read more details at: > > https://hpc.guix.info/blog/2020/06/reproducible-research-hackathon > > Hope to see you on Friday. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-01 4:57 ` Pjotr Prins @ 2020-07-01 9:10 ` zimoun 2020-07-01 9:21 ` Efraim Flashner 0 siblings, 1 reply; 17+ messages in thread From: zimoun @ 2020-07-01 9:10 UTC (permalink / raw) To: Pjotr Prins; +Cc: guix-devel, guix-hpc Hi Pjotr, Thank you for sharing your plans. On Tue, 30 Jun 2020 at 23:57, Pjotr Prins <pjotr.public12@thebird.nl> wrote: > GenNetwork1 depends on Python 2.4(!) with modules that have not been > updated this century, and an older version of Apache with mod_python, > amongst other things. We would like to use the guix time-machine > feature to run older versions on demand in containers, also for the > recent GeneNetwork2 version which runs on a modern Guix stack. When we > get it to work I would like to push the older packages in Guix-Past. I guess that the recent commit [1] by Efraim is part of this effort. :-) By container, what do you have in mind: guix time-machine --channels=file.scm \ -- environment --container or -- pack -f or -- system *-image ? 1: https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/f9fe4d8ac2706834fcff477db8f5421de537d78e > Note that GeneNetwork requires a largisch MySQL/MariaDB (170GB) > which is also a snapshot in time. We have 5+ snapshots of that > database that go with 5+ versions of the code. We want to run them all > under Guix so we no longer have to care about the underlying Linux > distro. I agree that Guix does not have (yet!) good management of large data set. The /gnu/store is not designed for that, if I have correctly understood. Even we have already discussed Content-Addressable Storage (CAS) on gwl-devel@gnu.org, AFAIR, we have not ended up with a good plan. Well, it will not be fixed on Friday. :-) But for sure, it is something to keep in mind. So, see you on Friday. :-) Cheers, simon ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-01 9:10 ` zimoun @ 2020-07-01 9:21 ` Efraim Flashner 0 siblings, 0 replies; 17+ messages in thread From: Efraim Flashner @ 2020-07-01 9:21 UTC (permalink / raw) To: zimoun; +Cc: guix-devel, guix-hpc [-- Attachment #1: Type: text/plain, Size: 2484 bytes --] On Wed, Jul 01, 2020 at 11:10:23AM +0200, zimoun wrote: > Hi Pjotr, > > Thank you for sharing your plans. > > On Tue, 30 Jun 2020 at 23:57, Pjotr Prins <pjotr.public12@thebird.nl> wrote: > > > GenNetwork1 depends on Python 2.4(!) with modules that have not been > > updated this century, and an older version of Apache with mod_python, > > amongst other things. We would like to use the guix time-machine > > feature to run older versions on demand in containers, also for the > > recent GeneNetwork2 version which runs on a modern Guix stack. When we > > get it to work I would like to push the older packages in Guix-Past. > > I guess that the recent commit [1] by Efraim is part of this effort. :-) Part of the effort :) I have a bunch more older packages that I'll probably push to guix-past as time goes on. Right now I have a no-longer-working octave-3.4.3 with some deps, apache-2.2 and possibly php-5.6. They're possibly ready to push as-is, but I want to make sure they actually work for some task before adding them. > > By container, what do you have in mind: > guix time-machine --channels=file.scm \ > > -- environment --container > or > -- pack -f > or > -- system *-image > > ? I think we're looking at 'guix system container' so it can be a "standard" guix service using them (as much as custom guix services are standard). > > 1: https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/f9fe4d8ac2706834fcff477db8f5421de537d78e > > > > Note that GeneNetwork requires a largisch MySQL/MariaDB (170GB) > > which is also a snapshot in time. We have 5+ snapshots of that > > database that go with 5+ versions of the code. We want to run them all > > under Guix so we no longer have to care about the underlying Linux > > distro. > > I agree that Guix does not have (yet!) good management of large data > set. The /gnu/store is not designed for that, if I have correctly > understood. Even we have already discussed Content-Addressable Storage > (CAS) on gwl-devel@gnu.org, AFAIR, we have not ended up with a good > plan. Well, it will not be fixed on Friday. :-) > > But for sure, it is something to keep in mind. > > > So, see you on Friday. :-) > > Cheers, > simon > -- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-06-30 12:40 Reproducible Research Hackathon: Friday, July 3rd simon tournier 2020-07-01 4:57 ` Pjotr Prins @ 2020-07-03 17:10 ` zimoun 2020-07-03 17:36 ` Ricardo Wurmus ` (2 more replies) 1 sibling, 3 replies; 17+ messages in thread From: zimoun @ 2020-07-03 17:10 UTC (permalink / raw) To: simon tournier, guix-devel, guix-hpc Dear, Thank you all for joining! A PAD is still open at: https://mensuel.framapad.org/p/guix-hackathon-9hlj?lang=en Please add whatever you have been up. Or drop an email. We are interested to hear your feedback. Especially about what pass, what fail and what you have learnt, if you enjoyed the experience, or on the contrary if you not, what could be improved for the next round. Personally, I spent the day with the good ol' Fortran and codes using the norm 77. And I have enjoyed the flexibility of Guix: navigate between the versions, running in container, etc.. For example, guix time-machine -C channels.scm -- build -L . foo guix time-machine -C channels.scm \ -- environment --container -L . foo --ad-hoc bar@x.y [env] ./configure --with-bar=xx && make And Guix helps a lot to expose "hidden" dependencies, i.e., not always explicitly mentioned in paper's instructions. Well, something that I learnt is you need some resource at hand, at least download or build the substitutes in advance. The "g77" issue [1] is not tackled but some points have been raised, so maybe soonish. :-) 1: https://github.com/ReScience/submissions/issues/41 On the Guix side, a missing feature is to search back in history, i.e., somehow improves [2] (which starts 2019-01-01) and be able to find the commit (or range of commits) which provided foo@x.y and bar@a.b 2: https://data.guix.gnu.org/repository/1/branch/master/package/boost Well, thank you all again! And hope to see you again on #guix-hpc. :-) Cheers, simon ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-03 17:10 ` zimoun @ 2020-07-03 17:36 ` Ricardo Wurmus 2020-07-03 17:56 ` Paul Garlick 2020-07-04 9:51 ` Konrad Hinsen 2 siblings, 0 replies; 17+ messages in thread From: Ricardo Wurmus @ 2020-07-03 17:36 UTC (permalink / raw) To: zimoun; +Cc: guix-devel, simon tournier, guix-hpc zimoun <zimon.toutoune@gmail.com> writes: > On the Guix side, a missing feature is to search back in history, i.e., > somehow improves [2] (which starts 2019-01-01) and be able to find the > commit (or range of commits) which provided foo@x.y and bar@a.b > > 2: https://data.guix.gnu.org/repository/1/branch/master/package/boost I have been using things like “git log | grep -B10 "boost: Update"” to find the commit updating a package, and then “git show caffebabe…:gnu/packages/boost.scm” to view the file at the time of that commit. -- Ricardo ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-03 17:10 ` zimoun 2020-07-03 17:36 ` Ricardo Wurmus @ 2020-07-03 17:56 ` Paul Garlick 2020-07-03 18:19 ` zimoun 2020-07-03 21:17 ` Ricardo Wurmus 2020-07-04 9:51 ` Konrad Hinsen 2 siblings, 2 replies; 17+ messages in thread From: Paul Garlick @ 2020-07-03 17:56 UTC (permalink / raw) To: zimoun, simon tournier, guix-devel, guix-hpc Hi Simon, Thank you for organising the day. > We are interested to hear your feedback. Especially about what pass, > what fail and what you have learnt, if you enjoyed the experience, or on > the contrary if you not, what could be improved for the next round. One outstanding puzzle for me is to figure out how to test a package definition in a new channel. For example, I have cloned the guix-past repository and started to add a new package. However, what is the best workflow to attempt a build from the channel? Do you add the channel to the git checkout of guix? Best regards, Paul. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-03 17:56 ` Paul Garlick @ 2020-07-03 18:19 ` zimoun 2020-07-07 17:52 ` Paul Garlick 2020-07-03 21:17 ` Ricardo Wurmus 1 sibling, 1 reply; 17+ messages in thread From: zimoun @ 2020-07-03 18:19 UTC (permalink / raw) To: Paul Garlick, simon tournier, guix-devel, guix-hpc Dear Pauk, On Fri, 03 Jul 2020 at 18:56, Paul Garlick <pgarlick@tourbillion-technology.com> wrote: > One outstanding puzzle for me is to figure out how to test a package > definition in a new channel. For example, I have cloned the guix-past > repository and started to add a new package. However, what is the best > workflow to attempt a build from the channel? Do you add the channel > to the git checkout of guix? I do not know if it is the best but I do: guix build -L path/to/clone the-package guix install -L path/to/clone the-package -p /tmp/test /tmp/test/bin/the-package Otherwise, I put in a channels.scm file something like: --8<---------------cut here---------------start------------->8--- (list (channel (name 'kikoo) (url "file:////home/simon/path/to/clone") (branch "master")) (channel (name 'guix) ; avoid to recompute heavy derivations and build modules (url "https://git.savannah.gnu.org/git/guix.git") (commit "000c7a0f70248ccf9dc774ef23da3e26d142c610")) --8<---------------cut here---------------end--------------->8--- where commit is something I already have in /gnu/store, then: guix pull -C channels.scm -p /tmp/loc /tmp/loc/bin/guix install foo -p /tmp/test but it is less convenient. All the best, simon ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-03 18:19 ` zimoun @ 2020-07-07 17:52 ` Paul Garlick 0 siblings, 0 replies; 17+ messages in thread From: Paul Garlick @ 2020-07-07 17:52 UTC (permalink / raw) To: zimoun, simon tournier, guix-devel, guix-hpc Hi Simon, On Fri, 2020-07-03 at 20:19 +0200, zimoun wrote: > > I do not know if it is the best but I do: > > guix build -L path/to/clone the-package > guix install -L path/to/clone the-package -p /tmp/test > /tmp/test/bin/the-package This works for me if I use the command: $guix build -L /path/to/guix-past-checkout/modules the-package Many thanks for the tip. Best regards, Paul. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-03 17:56 ` Paul Garlick 2020-07-03 18:19 ` zimoun @ 2020-07-03 21:17 ` Ricardo Wurmus 2020-07-07 17:44 ` Paul Garlick 1 sibling, 1 reply; 17+ messages in thread From: Ricardo Wurmus @ 2020-07-03 21:17 UTC (permalink / raw) To: Paul Garlick; +Cc: guix-devel, guix-hpc, simon tournier Paul Garlick <pgarlick@tourbillion-technology.com> writes: > One outstanding puzzle for me is to figure out how to test a package > definition in a new channel. For example, I have cloned the guix-past > repository and started to add a new package. However, what is the best > workflow to attempt a build from the channel? Do you add the channel > to the git checkout of guix? I did this from the checkout of “guix-past”: GUIX_PACKAGE_PATH=$PWD guix build my-package -- Ricardo ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-03 21:17 ` Ricardo Wurmus @ 2020-07-07 17:44 ` Paul Garlick 0 siblings, 0 replies; 17+ messages in thread From: Paul Garlick @ 2020-07-07 17:44 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel, guix-hpc, simon tournier Hi Ricardo, Many thanks for this tip. > I did this from the checkout of “guix-past”: > > GUIX_PACKAGE_PATH=$PWD guix build my-package > First, I changed directory to the 'modules' directory in the guix-past checkout. Then the 'guix build' command can follow the subdirectories and find the package definitions. Best regards, Paul. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-03 17:10 ` zimoun 2020-07-03 17:36 ` Ricardo Wurmus 2020-07-03 17:56 ` Paul Garlick @ 2020-07-04 9:51 ` Konrad Hinsen 2020-07-13 13:41 ` Ludovic Courtès 2 siblings, 1 reply; 17+ messages in thread From: Konrad Hinsen @ 2020-07-04 9:51 UTC (permalink / raw) To: zimoun, simon tournier, guix-devel, guix-hpc Hi Simon et al., > We are interested to hear your feedback. Especially about what pass, > what fail and what you have learnt, if you enjoyed the experience, or on > the contrary if you not, what could be improved for the next round. For me this was the occasion to finally start playing with a channel (guix-past), which has been on my agenda for a while. It was much easier with people around to answer practical questions that would take a long time to resolve by going through the documentation. It was also a good occasion for thinking about how to package artifacts of historical interest (i.e. recording release dates as metadata). In terms of packaging techniques, there wasn't much new in it for me. Python 2.4 is handled very much like Python 2.7, and since I installed all this stuff by hand many times back in 2008, it felt almost familiar. There is an interesting issue left for me to explore, which is why Python 2.4 compiled with today's gcc has a bug that it definitely didn't have back then. It's probably related to the many intentional ambiguities in the C language standard, check out John Regehr's blog (https://blog.regehr.org/) for interesting examples. That could become a selling point for Guix because we have the option of compiling old software with old compilers, which is hard with other infrastructures. Cheers, Konrad ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-04 9:51 ` Konrad Hinsen @ 2020-07-13 13:41 ` Ludovic Courtès 2020-07-14 8:13 ` Konrad Hinsen 0 siblings, 1 reply; 17+ messages in thread From: Ludovic Courtès @ 2020-07-13 13:41 UTC (permalink / raw) To: Konrad Hinsen; +Cc: guix-devel, guix-hpc, simon tournier Hi Konrad, Konrad Hinsen <konrad.hinsen@fastmail.net> skribis: > There is an interesting issue left for me to explore, which is why > Python 2.4 compiled with today's gcc has a bug that it definitely didn't > have back then. It's probably related to the many intentional > ambiguities in the C language standard, check out John Regehr's blog > (https://blog.regehr.org/) for interesting examples. That could become a > selling point for Guix because we have the option of compiling old > software with old compilers, which is hard with other infrastructures. Apologies for the delay. What was this bug exactly? I know Bonface addressed an issue related to how the Python 2.4 build system would capture the kernel version via ‘uname’ a build time: https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/d1977f5dccd73341f363cfa8d58ae3f2b2700ad7 But presumably you’re referring to something else, right? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-13 13:41 ` Ludovic Courtès @ 2020-07-14 8:13 ` Konrad Hinsen 2020-07-14 8:54 ` Bonface M. K. 2020-07-14 13:18 ` Ludovic Courtès 0 siblings, 2 replies; 17+ messages in thread From: Konrad Hinsen @ 2020-07-14 8:13 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, guix-hpc, simon tournier Hi Ludo, > Apologies for the delay. What was this bug exactly? > > I know Bonface addressed an issue related to how the Python 2.4 build > system would capture the kernel version via ‘uname’ a build time: > > https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/d1977f5dccd73341f363cfa8d58ae3f2b2700ad7 > > But presumably you’re referring to something else, right? Indeed. The details are here: https://gitlab.inria.fr/guix-hpc/guix-past/-/issues/1 Since I won't be able to look into this before my summer vacations, I opened an issue as a reminder. Cheers, Konrad ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-14 8:13 ` Konrad Hinsen @ 2020-07-14 8:54 ` Bonface M. K. 2020-07-14 19:53 ` Konrad Hinsen 2020-07-14 13:18 ` Ludovic Courtès 1 sibling, 1 reply; 17+ messages in thread From: Bonface M. K. @ 2020-07-14 8:54 UTC (permalink / raw) To: Konrad Hinsen; +Cc: guix-devel, Ludovic Courtès, simon tournier, guix-hpc Konrad Hinsen <konrad.hinsen@fastmail.net> writes: > Hi Ludo, > >> Apologies for the delay. What was this bug exactly? >> >> I know Bonface addressed an issue related to how the Python 2.4 build >> system would capture the kernel version via ‘uname’ a build time: >> >> https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/d1977f5dccd73341f363cfa8d58ae3f2b2700ad7 >> >> But presumably you’re referring to something else, right? > > Indeed. The details are here: > > https://gitlab.inria.fr/guix-hpc/guix-past/-/issues/1 > > Since I won't be able to look into this before my summer vacations, > I opened an issue as a reminder. > > Cheers, > Konrad > That's strange. To get the right results, you'd have to do a `2L ** 64`. When I tried `2 ** 63` I got `-9223372036854775808`. There's also an overflow error. Here's a snippet of what fails from Python-2.4.6/Lib/test: ``` # If this fails, probably using a strict IEEE-754 conforming libm, and x # is +Inf afterwards. But Python wants overflows detected by default. try: x = math.exp(1000000000) except OverflowError: pass else: raise TestFailed("overflowing exp() didn't trigger OverflowError") ``` Maybe there's an overflow somewhere and we'd have to tweak libm? I'm speculating though. I'd have to investigate this later. -- Bonface M. K. (https://www.bonfacemunyoki.com) One Divine Emacs To Rule Them All GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-14 8:54 ` Bonface M. K. @ 2020-07-14 19:53 ` Konrad Hinsen 0 siblings, 0 replies; 17+ messages in thread From: Konrad Hinsen @ 2020-07-14 19:53 UTC (permalink / raw) To: Bonface M. K.; +Cc: guix-devel, Ludovic Courtès, simon tournier, guix-hpc Hi Bonface and Ludo, > That's strange. To get the right results, you'd have to do a `2L ** 64`. Exactly. The long integer arithmetic works fine, it's the detection of the overflow of 64-bit ints that fails. > When I tried `2 ** 63` I got `-9223372036854775808`. There's also an Good catch, I hadn't tried that one! > Oooh, thank you! It looks like an “interesting” bug, one of those > that can help make the case for precise software environment control. > :-) Exactly. Most people have understood by now that Python and libraries higher up on the stack suffer from breaking changes, but C and libc/libm, that's still the unshakable ground on which software can safely be built. > Uh, weird! We could check whether building Python with ‘-fwrapv’ helps. > See also <https://lwn.net/Articles/511259/>. Interesting. I am finding out that I don't know most of the possible suspects in this crime story ;-) Cheers, Konrad ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Reproducible Research Hackathon: Friday, July 3rd 2020-07-14 8:13 ` Konrad Hinsen 2020-07-14 8:54 ` Bonface M. K. @ 2020-07-14 13:18 ` Ludovic Courtès 1 sibling, 0 replies; 17+ messages in thread From: Ludovic Courtès @ 2020-07-14 13:18 UTC (permalink / raw) To: Konrad Hinsen; +Cc: guix-devel, guix-hpc, simon tournier Hi Konrad, Konrad Hinsen <konrad.hinsen@fastmail.net> skribis: > Indeed. The details are here: > > https://gitlab.inria.fr/guix-hpc/guix-past/-/issues/1 Oooh, thank you! It looks like an “interesting” bug, one of those that can help make the case for precise software environment control. :-) bonfacemunyoki@gmail.com (Bonface M. K.) skribis: > That's strange. To get the right results, you'd have to do a `2L ** 64`. > When I tried `2 ** 63` I got `-9223372036854775808`. There's also an > overflow error. Here's a snippet of what fails from > Python-2.4.6/Lib/test: > > ``` > # If this fails, probably using a strict IEEE-754 conforming libm, and x > # is +Inf afterwards. But Python wants overflows detected by default. > try: > x = math.exp(1000000000) > except OverflowError: > pass > else: > raise TestFailed("overflowing exp() didn't trigger OverflowError") > ``` > > Maybe there's an overflow somewhere and we'd have to tweak libm? I'm > speculating though. I'd have to investigate this later. Uh, weird! We could check whether building Python with ‘-fwrapv’ helps. See also <https://lwn.net/Articles/511259/>. Ludo’. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2020-07-14 19:54 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-06-30 12:40 Reproducible Research Hackathon: Friday, July 3rd simon tournier 2020-07-01 4:57 ` Pjotr Prins 2020-07-01 9:10 ` zimoun 2020-07-01 9:21 ` Efraim Flashner 2020-07-03 17:10 ` zimoun 2020-07-03 17:36 ` Ricardo Wurmus 2020-07-03 17:56 ` Paul Garlick 2020-07-03 18:19 ` zimoun 2020-07-07 17:52 ` Paul Garlick 2020-07-03 21:17 ` Ricardo Wurmus 2020-07-07 17:44 ` Paul Garlick 2020-07-04 9:51 ` Konrad Hinsen 2020-07-13 13:41 ` Ludovic Courtès 2020-07-14 8:13 ` Konrad Hinsen 2020-07-14 8:54 ` Bonface M. K. 2020-07-14 19:53 ` Konrad Hinsen 2020-07-14 13:18 ` Ludovic Courtès
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.