Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Tests fail, expecting more libs to be loaded #94
The CI tests are currently failing. A quick fix is to uncomment all the libraries listed in libs.arc.
@hjek, was there a reason you commented these out a while ago? And is there some sort of rubric you're using for calling them "optional"? I would uncomment them myself, but it looks like you have something in mind with what you're doing, and I might trample on that.
Oops. I'll look into this.
I've been going through some of the many libraries that come in the repo, and some currently work and are quite interesting (in particular the
The libraries that are commented out in
I'd guess the issue here is that I've accidentally commented out one library that is not strictly required by News, yet still needed for the unit tests to pass.
I'm fine looking into it soon, but of course it's fine if you can look at it / fix it (and I don't see that as trampling).
The way I fixed this was to have most of the tests load the libraries they depend on, with one significant exception:
I uncommented lib/make-br-fn.arc and moved to the "core" list. I did this because it's one of the incompatible changes in Anarki that's documented in the CHANGES/ directory, so for it not to be active all the time would be a little odd.
Unfortunately, I suspect this file could contribute somewhat to Anarki's startup time, since it changes the
Then again, Arc already does ssexpansion for all code, so whatever this adds might not be that bad. Arc loads pretty fast for me either way, so I'm not sure.
@hjek, if you notice this causes a substantial regression in load times, I think we have lots of options. Not too much really depends on make-br-fn.arc (just a few things in util.arc, ppr.arc, and client.arc.). We can probably refactor those files, the way make-br-fn.arc works, and the CHANGES/ documentation so it isn't running an expensive string-processing operation for every occurrence of
I don't exactly want to say make-br-fn.arc is sacred. I'm just explaining why I reintroduced it: Because it would take a few changes across several files to properly remove it (or alternatively to move it to its own non-conflicting library). If reintroducing it is fine for your startup time purposes, then that sounds good to me.
Before I close this, I also want to elaborate on what I had missed the first commit that required a second one. Anarki is a Racket package (and I should know, because I made it so :-p ). As such, it a certain process it goes through when installing the package or running the Racket's unit test runner.
In the Travis CI script, I already have it running
So I ran the
Once I deleted and reinstalled Racket, I ran these commands and it all worked out fine.
Hm. It looks like there's one more place the CI tests are failing. This time it's not Travis CI, but by the CI testing at the Racket package catalog:
It looks like the tests are still failing because some output is sent to stderr when one of the *.rkt modules is run. It looks like there's something of a dicrepancy between the testing command
I'll see what I can do to make this work.
I feel like the "initializing arc" message should show when running Anarki at the command line, but that it shouldn't show when running Anarki programmatically through the
The error seems to be related to a bug in Racket that was introduced in version 6.3. I tried on several of the latest versions of Racket on Linux, and the most recent versions seem to work:
Looking through Racket's commit history, I notice that indeed there's a fix for this just before version 6.11. (Hey, there's also a fix for text input streams on Windows! I hope that fixes the pasting-at-the-REPL issue.)
I tested with various old versions of Anarki too. It looks like this error started happening during my contributions last year, beginning with commit 2946803, which coincidentally(?) is the first commit where the Travis CI tests first started to work. This "lifted.0" error does sound distantly familiar... Maybe I saw it failing on the Racket package index at one point and just put it out of mind because I had no idea what to do about it.
I tinkered a little bit with that commit, and removing ac.scm's new dependency on
So it seems we have two pretty reasonable options here:
Okay, I got Travis CI working. I used the
I notice the Racket package index shows "build: succeeds" now. Success! I count that as enough to close this ticket, but I did a few more things to be sure:
I tested on several versions of Racket and determined the earliest one where the tests pass is now Racket 6.3 (much earlier than before). So I tweaked the Travis CI tests to test on two versions in particular: Racket 6.3 and Racket 6.12 (the current Racket version). That's represented in commit 21fec6a.
I developed a new implementation of arc.cmd on Windows so I could get run-news.cmd working (commit e7a44df). This new implementation contains almost no code that can't run equally well on Linux and OS X, so I hope it'll make it easier to maintain feature parity of the command-line interface without actually needing to test on Windows.
I tried the unit tests locally on Windows 10, and they needed no extra attention there. They're already passing!
Looks like the tests pass in every way I can think of, and some of the discrepancies between those different tests are more streamlined now.
@akkartik I hear what you're saying: It's fine to put a note in the readme about Racket version incompatibilities if the fix is elusive. I think this time, I found all the fixes I needed. I nevertheless left notes in .travis.yml to explain why we seem to run up against various version limits in particular.
That's really perfect, thanks!! Very thorough docs in
(Everything's working for me as well.)
The Readme already says we require Racket v6.8 or later. So it shouldn't need any further change.