@ben @notjack Done

What does it mean when the Travis CI build fails? I submitted a pull request that’s causing the travis build to fail with GCC errors even though I didn’t touch any of the C code. https://github.com/racket/racket/pull/1726

@cfinegan it’s not clear to me what’s going on with those build failures

I think that something’s wrong with subprocess handling on linux on master, based on @mflatt’s recent changes

Okay, I wanted to confirm that it wasn’t an issue with the changes in my fork.

@cfinegan It’s probably not an issue with your changes, but I think your branch doesn’t include the rktio changes that samth has in mind

@mflatt while @cfinegan’s branch doesn’t have those changes, Travis tests the merge of that with master

the revision tested is here: https://github.com/racket/racket/commit/4da654e8fdeee6d196979af760f98bd4bba15732

Ok, that’s good to know. I’m not seeing that particular failure elsewhere, but I’ll watch for it.

@mflatt the errors I see in @cfinegan’s PR tests are the same ones I see in the tests for master — timeouts either in git-related pkg tests, or in the regular subprocess tests

I don’t know if that’s related to your most recent change though

I’m seeing the pkg-test failures, and I hope the most recent change addresses those. I’m probably not looking at the right variant to see the subprocess example; can you point me to one?

here’s an example: https://travis-ci.org/racket/racket/jobs/244965444

Oh – it’s the ones with places & futures disabled. Now I know how to find the bug.

Great

Is “require all modules in directory X” a reasonable thing to do? or does it have subtle problems with when exactly the directory is read based on when modules are compiled?

@notjack It wouldn’t be supported well by tools like raco make, which can’t deal with a dependency on a directory

@mflatt what would it take to make raco make aware of unusual dependencies like that?

I’m not sure. One complication is assigning a hash code to the directory. Another is that creating a “compiled” subdirectory would change the enclosing directory, which would be interpreted as a need to recompile. I bet there are more complications that I won’t think of offhand.

How does the planet require form work with raco make?

The default module name resolver calls out to planet-module-name-resolver when it sees planet

Other tools similarly have hard-wired support for planet, which helps explain a class of problems that PLaneT has

huh, never would have guessed that but it makes sense

yeah, when splitting the old code into pkgs, I tried to remove planet from “base” but was unsuccessful

@mflatt with your latest changes, only the --disable-jit tests failed, and that may just be the tests in general taking too long; I’m rerunning it (https://travis-ci.org/racket/racket/builds/245045634?utm_source=slack&utm_medium=notification)

more generally our tests have gotten to the point where we have lots of intermittent failures from hitting the time limit; we should probably either speed some up or run fewer tests

@cfinegan got time for some questions about racket/rackunit#44?

@samth Is it just a pure timeout or are these performance tests? If the former, you might want to dynamically pick the timeout based on the machine & load. If the latter, my test framework has a benchmark test type that does curve fitting and asserts the R^2 value instead of the time. Makes it much more CI/VM proof.

@zenspider It’s the former, and it’s the Travis timeout, not ours

see https://travis-ci.org/racket/racket/jobs/245059751 for an example

the major problem is that the pkg tests take about 20 minutes

I didn’t realize that travis had a global timeout. I’ve worked on many projects that take a really long time on CI

yeah, it’s about 45 minutes

I think that’s configurable… definitely had projects that went over that before I got to them (I hate long test times)

oh… but maybe those projects were on circleci…

easy parallelization options there too

this doesn’t parallelize well either, because you have to build racket to start with

@samth: you’re not parallelizing the make phase: make CPUS="2" PKGS="racket-test db-test unstable-flonum-lib net-test" CONFIGURE_ARGS_qq="$RACKET_CONFIGURE_ARGS"

IIRC, racket does build well with -j N

CPUS=2 does that

but also parallelizes raco setup

@notjack might not be able to get to everything until tomorrow morning, but I’m happy to take questions

I don’t think so… I think you still need -j… checking.

I promise, that does it

CPUS=N exists because you can’t get the value passed to -j to use with raco setup

cfinegan: No rush

I get the raco side of it wrt ENV… CPUS is not described at all throughout the gnu make doco. It’s really obtuse doco, but seems thorough.

no, CPUS is part of the racket makefile

My first impression is that the filtering logic seems complex and out of place, but I agree filtering is useful and thank you for working on it.

see this code: https://github.com/racket/racket/blob/master/Makefile#L45-L53

I’m post workout, so I’m probably not explaining myself well…

how specifically do you intend to use the filtering? in DrRacket with test submodules and without test suites and only checks? in CI with test suites? some other combination?

gotcha… kk. Could also tune it. I’ve found for GCC being mostly IO bound that nproc*2 often works quite well.

that’s true for the C build step, but not for the raco setup build step

but the C build on Travis takes very little time

thank you for having such a clean makefile…

Really we just need to make some of the tests faster

I can’t see how long just the C side takes… but that whole thing is 15 minutes. That’s 1/3rd the total timeout.

you could break up the raco vs gcc side and scale accordingly… but… I’ll shut up now. you obviously have this in hand and I’m just making noise at this point

sadly we don’t have it in hand

hah. well… let me know if i can help

well, if you can make the pkg tests faster … :slightly_smiling_face:

or even figure out which ones are particularly slow

that would be a big help

I was curious… @mflatt was working on nuking C for chez… but then I saw a 10kloc diff for revamping IO in C. Is that a precursor to make porting easier?

yes

the rktio library is intended to be usable from other places (such as Chez)

I’m excited about the chez port, even if it is initially slower, I suspect it’ll help in the medium+ term a lot

I’m also excited

I was blown away by a recently published table of scheme benchmarks… chez was fairly consistently 1st–2nd place. Racket often in the top 5. I had no fucking idea… chicken always FELT faster because startup costs were zero, but overall perf was shite

I should have dug in on those benchmarks to see if they were using /base

Chez is very good, although those benchmarks somewhat overstate the advantage over Racket

Chez is best on old-school Scheme code — lots of plain functions and s-expressions

basically.. the same problems all benchmarks have :stuck_out_tongue:

more user-defined data structures and tricky indirections reduce the advantage

which isn’t to say that it isn’t still there

you(? I think) helped me make a CPU simulation fast for advent of code… really nice thing to study. Then I saw a chez impl that used define-register and… fuck. it was soo fast

I didn’t understand it… but FAST

@samth in general, what effect do functions-stored-in-structs have on Chez’s optimizations?

is that sort of thing tricky to handle?

@notjack I don’t think I could give a useful answer there

that’s certainly trickier