> On Nov 11, 2014, at 3:55 AM, Jed Brown <j...@jedbrown.org> wrote: > > KAUST (or KSA?) internet can be flaky at times and my "make" was > (silently) hanging indefinitely while trying to connect to mcs.anl.gov. > Manually touching .nagged allows my build to proceed. The hang could be > fixed by adding a reasonable timeout, but I can't find a timeout in > urllib. Aron suggests that I try curl because all built-in Python url > libraries are terrible, but I don't think we can depend on curl being > installed, so we'd have to fall back to something. We could implement a > timeout using threads, if threads weren't broken on some architectures.
I agree it is inexcusable for the nag to hang the compile I have switched the code to use urllib2 and time out after 2 seconds. I cannot test it because I don't have access to a flaky connection which hangs when a network connection is attempted. (For example if I disconnect from the network and use urllib it returns immediately with an exception so the user sees no hang). Branches barry/add-timeout-nag and next > > Meanwhile, the professor next to me runs Little Snitch on his Mac and > wants to know why PETSc's build is trying to connect to Argonne's > servers. His first thought was that it was a there for surveillance. > > > PETSc has a significant number of users that work behind firewalls or > are otherwise sensitive to outgoing connections. Although nagupgrade > helps people stay updated and reduces some support email, I think it is > unprofessional and a failure mode that I'd rather avoid. Actually it is un-amateur in that almost all professional software does do various network connections without specific request by the use and it is only the Richard Stallman fanatic amateur crowd that that refuses to take advantage of this power. Note that nag does not send any version information to the ANL server; note also that we could change the nag to obtain the version information from bitbucket.org or other locations if they are perceived as less threatening than ANL. Ok I've made that change, it now gets the version information from the bitbucket site. Ignoring the paranoid crowd, there is still an issue with the nag. If the user has write access to $PETSC_DIR then it will only nag them once every 24 hours; if they do not have write access to $PETSC_DIR it will nag them on every make with the PETSc makefiles. I would have preferred to use ~/.petscnag or `pwd`/.petscnag but Jed believes that a package dumping a file there is evil incarnate (even though Emacs does it). Note that on Microsoft Windows I would use the Registry to store this information; it is unfortunate the "unix-like" world doesn't have "places" where this type of state can be kept (well it does, it is called the file system). Barry
