@dan: Will do, thank you.

@cowbs I haven’t seen that before, but @mflatt might have an idea or maybe reporting on the mailing list or on github is the right thing

@cowbs Is the issue that raco setup should be able to write that ".dep" file, or that it shouldn’t be trying to write it? If it’s the latter, are all ".zo" and ".dep" files newer (by filesystem timestamp) than corresponding ".rkt" sources?

@mflatt What it looks like to me is parallel jobs racing each other to generate the same .dep and .zo files and stomping over each other as a result. Once everything has been built there is no issue. Ideally a user who syncs our 6.8 folder shouldn’t have to build them at all but that’s a separate issue.

Parallel jobs should not try to build the same file, at least if they’re all from the same raco setup, because there’s a managing process that hands out permission to build a given file. If you turn on output of debug@setup/parallel-build with something like racket -W "debug@setup/parallel-build error" -l- raco setup do you see multiple processes compiling the same file?

Sorry, should’ve clarified, this isn’t being invoked from raco setup but rather our own racket program’s main. I’ll run it with the debug.

@mflatt the Travis tests for the release branch consistently fail with an unbound variable, indicating the bug in the new expander that we’ve seen for a while

however, building those same tests on my machine does not produce that error, sadly

is there something useful we can do to debug on travis?

@cowbs see also the PLT_COMPILED_FILE_CHECK environment variable, added in v6.6, that turns off the file-timestamp check if you set it to exists

Okay, I e-mailed you the complete output

@samth I’m able to get that error with a release build on my machine, so I’ll investigate more

@mflatt ah, great!

Well, I’m able to get the same error as the Mac build on Travis; is that the right one?

exception raised while running test case contract-arrow-star-optional25b?

@cowbs It does look like multiple attempts to compile some files… I’m not sure the log means what I think it means, though, so I’ll still looking. Does your program drive compilation by calling parallel-compile-files?

Yes

@mflatt if it’s an unbound variable error in the contract tests, then that’s the right one

My recollection is that when this error has appeared in other places, the printed scope sets in the error message seem to be subsets in the right way

@cowbs Oh… Taking things from the top, using parallel-compile-files (or raco make) will not work if any modules involved in the implementation of parallel-compile-files are not already in sync. The raco setup tool has special bootstrapping support to be able to compile its own implementation, but compilation won’t work right otherwise.

Ahh okay.

@mflatt so ensuring that everything used by parallel-compile-files is built properly (using raco make or raco setup) should neatly sidestep this current issue?

I think probably so; I’m not 100% sure that an out-of-sync base is causing this specific problem, but an out-of-sync base will definitely cause problems

@cowbs it seems like everyone needs to run a “install” step after syncing racket 6.8

Or we push that exists check mode and rely on us keeping the zo’s in perforce up to date and correct.

i don’t think parallel-compile-files pays attention to that

@danl-ndi It should — this is the case (and client) that it was designed for

ah… that might be a good fix us

we also just discovered that —compiled parameter can take an absolute path and the empty entry to preserve usage of the racket distro’s zo files

With that environment variable set I’m not seeing any of our own zo’s build with parallel-compile-files

they’re not getting *re*built, right?

I deleted all *.zo and *dep files from our plt compiled directories, and they’re not regenerated when I do dco.cmd —precompile

the directories are still there, however

(doesn’t seem to make a difference)

I do still have -W "debug@setup/parallel-build error" as an argument, and nothing is printed from that.

@mflatt looking at your patch, am I correct that this is the relevant portion of the code in Chez (https://github.com/mflatt/not-a-box/blob/master/core-hamt.ss#L348-L351) and that the code argument that’s wrong isn’t present in the Chez code?

Yes

samth: You know how TR displays all the type errors, not just the first one. That’s cool. Do any of the papers explain that? There’s some subtlety it seems like because rule might have to return a type even if it doesn’t have a type or something that should be an arrow isn’t so the structure of the rule breaks down

@jeapostrophe Bottom/Error (I forget exactly which when) get inserted at times when things don’t check. Both are valid arrow types via subtyping

I don’t think is is described in any TR papers

pnwamk: Cool, and rather than destructing the return type, you just check that it is in the sub-type relation, then at the end do something like “Is the set of errors empty?”

I believe so — I’d have to double check (I haven’t hacked much on the error handling code but that seems right based on everything I’ve seen)

It’s very cute

It’s really easy to write a type-checker that sucks and just errors once

@jeapostrophe the type checking is handled as @pnwamk describes

the error handling is basically done via side effect

raise-type-error is a effectively a function that adds an error to a global list, and returns the Error type

and then we call a function at the end that iterates over that list, and raises errors unless the list is empty

note that it uses (error-display-handler) to raise multiple errors

one thing to think about: it’s easy for the Error type to leak places, and we don’t do a perfect job of eliminating downstream errors

to add to the fun of Error implementation wise, it’s both the top and bottom type (w.r.t. subtyping - yikes!), so we have to do special checks for it when computing things like type intersections to ensure operations have certain desirable properties (e.g. commutativity)

….how on earth can it be both the top and bottom type?

the subtyping function says it is

:wink:

sigh

(recall that Error is not a type that describes program values, but a tool to make the typechecker more user friendly, e.g. let us report all type errors in a program effectively)

Any Frog users: I’d welcome input on https://github.com/greghendershott/frog/pull/194

@greg as a rank Frog dabbler that seems good at first glance

a slightly more racket-y way to do .frogrc seems good

samth - cool