Is there a way to set the background color of a message%, or of the label of a choice% ?
I’m continuing to poke dynamic-rerequire and notice it doesn’t respect the use-compiled-file-check parameter, because get-module-code prefers .zo only when newer regardless of that parameter (unless you override the default choice using #:choose ). Should the get-module-code default be changed, or should dynamic-rerequire override the default?
I think having get-module-code respect that parameter when choosing the default seems sensible, although there might be something that breaks when you try it.
@greg the tests for http are failing regularly with an error about http://httpwatch.com\|httpwatch.com that I can’t replicate locally: http://drdr.racket-lang.org/57893/racket/share/pkgs/http/http/request.rkt
That’s strange because about 4 years ago I added a commit not to run the tests that do I/O on the package build server: https://github.com/greghendershott/http/commit/31382e11c8ebcb99d094f85d831a192d87cfc597
Is it possible that the environment variable PLT_PKG_BUILD_SERVICE is no longer defined there? Did that change recently??
- That error is on DrDr, not the pkg build service.
- DrDr has full internet access, so that shouldn’t be a problem
- This error was somewhat intermittent.
IIRC, sometimes things wouldn’t work due to (maybe) Travis CI or GitHub Actions being on white lists that maybe the package build server (or DrDr?) would not be. At least that was my working theory. Anyway things would work pretty consistently on Travis/GHA, and get tested that way, at least.
So the exclusion seemed to make sense.
Maybe I should do a similar exclusion for DrDr.
I think it’s the pragmatic thing to do, probably, at least for today.
I can root around the docs but do you happen to know some magic env var, for “I am running under DrDr”? (similar to PLT_PKG_BUILD_SERVICE)
the pkg build server has no internet access
so that’s different
OK I guess I don’t remember the history of that on the pkg build server, and the rationale for that commit.
All the tests including http://www.httpwatch.com\|www.httpwatch.com pass for me, locally, just like you reported. I’m not immediately sure what’s up between DrDr and http://httpwatch.com\|httpwatch.com.
There is an env var for DrDr (I think it’s DRDR)
If there’s something you can add to make it print more information that would be useful.
Does DRDR have good DNS? Can you run nslookup or dig or host and resolve the name? tcp-connect: connection failed;
host not found
address: <http://www.httpwatch.com\|www.httpwatch.com>
the server is using 8.8.8.8 and gets good results from dig but failures with host, so maybe that’s what’s going on
nslookup also works correctly and uses 8.8.8.8
actually I have no idea what’s going on
dig <http://www.httpwatch.com\|www.httpwatch.com> fails, saying it used 8.8.8.8. But dig @8.8.8.8 <http://www.httpwatch.com\|www.httpwatch.com> succeeds. That’s on the drdr machine.
On my local machine some things work and some things don’t, with no pattern at all
Hmm, is it only using 8.8.8.8 or is there another resolver?
Sounds like <hand-wavy> caches and networks :ghost:
As far as I can tell, the drdr machine (which is called hurin) only uses 8.8.8.8
my local machine has a different dns server by default
which I think is my router
looking at 1.1.1.1, it gives the same answer everywhere
[samth@hurin:~ ] host -v <http://www.httpwatch.com\|www.httpwatch.com>
Trying "<http://www.httpwatch.com\|www.httpwatch.com>"
Host <http://www.httpwatch.com\|www.httpwatch.com> not found: 2(SERVFAIL)
Received 35 bytes from 8.8.8.8#53 in 2021 ms
[samth@hurin:~ ] host <http://www.httpwatch.com\|www.httpwatch.com>
Host <http://www.httpwatch.com\|www.httpwatch.com> not found: 2(SERVFAIL)
[samth@hurin:~ ] host <http://www.httpwatch.com\|www.httpwatch.com>
<http://www.httpwatch.com\|www.httpwatch.com> is an alias for <http://httpwatch.azurewebsites.net\|httpwatch.azurewebsites.net>.
<http://httpwatch.azurewebsites.net\|httpwatch.azurewebsites.net> is an alias for <http://waws-prod-blu-015.vip.azurewebsites.windows.net\|waws-prod-blu-015.vip.azurewebsites.windows.net>.
<http://waws-prod-blu-015.vip.azurewebsites.windows.net\|waws-prod-blu-015.vip.azurewebsites.windows.net> is an alias for <http://waws-prod-blu-015.cloudapp.net\|waws-prod-blu-015.cloudapp.net>.
<http://waws-prod-blu-015.cloudapp.net\|waws-prod-blu-015.cloudapp.net> has address 191.236.16.12
I have no explanation
that’s running in quick succession
I tested with a ubuntu docker image configured to 8.8.8.8 and wasn’t able to reproduce.
Host <http://www.httpwatch.com\|www.httpwatch.com> not found: 2(SERVFAIL) This makes me wonder if perhaps the resolver isn’t receiving an answer from 8.8.8.8 before a timeout. This assumes that it’s using UDP for DNS. And the system should be exhibiting the same behavior for other names.
Seems like a short change to modcode: https://github.com/djholtby/racket/commit/5db1ec37189e7b2d42d9e04d01aa0cc3e25a3f64
From looking at the DrDr source I’m not confident DRDR is in the env for the program being tested. In good-init.sh it is defined — but not export ed. (Admittedly my shell script skills aren’t great.)
At http://drdr.racket-lang.org/help I do see this advice:
> What should I do if I know there is a problem but can’t fix it now? > > Have the program output raco test: @(test-random #t) to standard output. I wonder if I should do that??
That seems maybe orthogonal but idk.
That reduces the amount of email that some people get but not much
This isn’t really what random is intended for
Maybe I should check for the existence of /opt/svn/drdr (the value that good-init.sh sets its DRDR shell var to. That seems unlikely to exist in non-DRDR systems?
Something like (or (getenv "DRDR") (file-exists? "/opt/svn/drdr")).
Oops I meant directory-exists?.
(or (getenv "DRDR") (directory-exists? "/opt/svn/drdr")) is the least-worst test for running on DRDR, and therefore skipping the I/O tests, that I can think of, for now.
It’s a hack and it might break someday, but I could re-fix it, then.
I know @jeapostrophe is rarely on Slack but will ping anyway.
I would prefer not to skip this but instead to figure out what’s going on
and also if the environment variable is not set correctly we should fix that
In particular it seems like the problem is dns configuration on the machine and that should just be fixed
Ive changed the dns config which should help
10–4. I wonder if it’s relevant that http://drdr.racket-lang.org/57903/ for example shows <http://drdr.racket-lang.org/57903/pkgs/net-test/tests/net/dns.rkt> failing. Maybe the DNS config change you made will address that as well as the http package intermittent failures.
Unfortunately I now worry that I introduced that failure. I’ll have to check.
Well in that build there was no http package request failure, so I’m happy! Seriously — thanks for looking at this; let me know if there’s anything else I can do on my end.
I think that test will pass on the next run
or at least, I ran the binary currently under test on that file and it worked