somehow xvfb-run causes tests to have no output

or maybe that was just the framework tests hanging

no, the problem is that docker-compose run xvfb-run ... doesn’t work, have to wrap it in sh -c

@mflatt The most recent Travis build keeps hanging on linux in the file.rktl tests, and I have no idea why: https://travis-ci.org/racket/racket/builds/295988203

that’s probably caused by the daemon process that xvfb-run spawns not being reaped properly by xvfb-run when it runs as PID 1

which is one of the reasons I think xvfb should be in a different container

There’s one test that hasn’t worked under xvfb

which test?

The leak test in DrRacket

Mentioned in the issue I think

is that the one that jay mentioned in slack?

the one that needs a real X server instead of xvfb for some bizarre reason?

Probably

The tests have changed some since then

I think I’m confused. Is that related to the docker setup or an entirely separate issue?

ah I only just saw the commit you added to the PR

I’ll merge the PR as is unless you’ve got objections

my plan is to do the following next:

• Split gui tests into a separate Dockerfile
• Add config to docker-compose.yml to run one gui test service for each installer variant in addition to the non-gui test service
• Add a Dockerfile for an image that only runs xvfb
• Add an xvfb service to docker-compose.yml and update each gui test service to use that xvfb instead of wrapping tests in xvfb-run, to avoid process weirdness and make the tests run in an environment that’s more similar to how they’d run when talking to a real X server

that also means we could swap out the xvfb service for a different docker image that runs a real X server without changing any of the tests or test scripts

also: what exactly is the point of --skip-installed? shouldn’t raco pkg install just do that by default? or is it to avoid updating packages or something?

That plan sounds good, and I’m for merging now

ack

What I meant about the tests changing is that the DrRacket tests have been changed to avoid some concurrency problems

so that maybe more of them needed a real X server in the past

I also think --skip-installed should be the default behavior

but it isn’t

ah

how much do you know about the individual test suites run in the release tests?

it varies a lot, as you might expect

I wrote the match and TR tests, I don’t understand the DrRacket tests, other things are in between

from what I can gather, a lot of them are doing things that can tend to make tests flaky / unportable, and I’m wondering how much effort it would take to make some improvements there

making them less flaky would be good

but some of them are very un-maintained

and/or maintained by people with widely varying skill/time investment

(granted my point of comparison is my employer, where most tests are entirely capable of being executed across machine clusters where none of the machines even have hard disks…)

in general, we try to avoid flakiness in DrDr

but many of the release tests are not run there

also I presume DrDr does not run tests for every possible installation environment?

right

it’s just a particular machine

whereas the release tests should probably be run on each permutation of installation options

http://drdr.racket-lang.org/help

yes, although that isn’t currently done

how are the installers built from source anyways? is there a list of which commits to use from each of the racket repos that the release manager maintains somewhere?

yes

https://github.com/racket/racket/wiki/Release-process has a lot of detail

this repo https://github.com/racket/release-catalog has all the releases

ah hah!

that catalog repo is the part of the release process I was missing

@notjack: There’s yet more pieces, actually. :)

But many of them no one but me needs to bother with.

@stamourv let me first say that I’ve got enough projects already, but I like release automation and it seems like an area where I’m able to help a lot :)

Oooh, interesting.

I’m actually in the process of increasing automation for some of these hidden parts.

But the testing checklist that’s on the wiki is by far the most painful part.

The manual tests, especially.

well I do like testing

care to reveal more details, O Mysterious Vincent?

part of the reason I’m interested is because I have to remember to add new docker images for each racket version in my racket docker images repo and I always forget

Perhaps this is silly, but are there “placeholder” arguments for curried functions in Racket?

(curry fn _ _ 3)

@slack1 no, but the fancy-app package does something similar

Does Racket instead prescribe a different idiom?

I think Racket has no style recommendations on lambda shorthands

most folks use one of the following:

• the curry function, ((curry + 1 2) 3) => 6
• the cut and cute SRFI macros, ((cut + 1 2 <>) 3) => 6
• the fancy-app package, ((+ 1 2 _) 3) => 6
• the afl package, (#λ(+ 1 2 %) 3) => 6
• the curly-fn package, (#{+ 1 2} 3) => 6

hmmm, perhaps I shall check out the fancy-app package, but so far I haven’t been dowloading other people’s libraries

thanks

glad to help!

@notjack: No time right now, but I can tell you more later.

@slack1 srfi–26 (which has cut) should be available in racket without having to download someone elses package

Likewise my racket-travis repo

Anyone else have build problems on git HEAD? (edit: seems to happen for me on v6.11 too, I wonder if Racket doesn’t like something with my OS config…)

I get mprotect failed: 7f9ae8800000, 524288, 1, 12 during the collects setup.

I’m on commit 4f1ef42d071c060973b69de001ad577261f13a61 and should be a clean checkout since I just did git clean -fxd

Ah argh, looks like I recently built some networking software that modifies vm.max_map_count. Setting that too low can cause mprotect failures. I bet that’s it. Sorry for the noise.

@notjack @slack1 actually most people just use lambda

well yes there’s that