@wcheng_victor has joined the channel
@zenspider DrRacket’s colorer depends on the lexer giving it information to back up just enough to recolor. I’m guessing that something about the lexer prevented the colorer from going pack to the “p” to re-lex from there. Exactly what went wrong is difficult to guess, although I recall implementing error tokens wrong once or twice, maybe because it’s easy to have the wrong backup or not have the error range covered by a single token.
@samth On Travis tests: It looks like we spend about 15 minutes on make, about 8 minutes on racket-test-core, about 20 minutes on raco pkg tests, and a little while for the rest. What if we drop the raco pkg tests? Has that set of test ever exposed a problem via Travis that wasn’t discovered otherwise (either through DrDr or other tests)?
@mflatt I think we probably have at some point, but maybe not enough to be worth it (or worth trying to make the raco pkg tests faster)
let me look at the history for the pkg code
@mflatt Travis exposed some problems in the raco pkg tests themselves, and it’s possible that https://github.com/racket/racket/commit/a5f6bf34dc75e33dd8a09d6ee7c9ea509395feb2 was motivated by Travis tests (but hard to tell now)
that seems to be it that I can find
Not sure that’s enough of a positive record to be worth running 80 min of tests on every commit
@samth I don’t recall the immediate motivation there, either. Turning off the raco pkg test for Travis seems right to me.
@mflatt this is what I’m working from: http://beautifulracket.com/basic-2/the-syntax-colorer.html — seems straightforward to me. I would have thought it would always be going back some to do coloring… I do find it rather odd that it is creating a basic-lexer on each call. What if the language needed stateful info to tell?
I’ll look a little more, but to answer your last question, the coloring API supports an extended mode to let you thread through state (i.e., store-passing), so the colorer can keep track of which state to send back if it needs to resume from a particular point
hi @ryanc, may I ask how you were able to configure the build you used to test https://github.com/racket/racket/pull/1704 changes? I tried doing a local merge with the master branch but the build keeps failing with Racket aborting in middle of raco setup so I’m currently unable to replicate the errors you got.
I do totally believe you :slightly_smiling_face: and I understand that my code caused SQL_BUSY status codes to be converted into raised exceptions, breaking automatic retry. I’m just concerned that I’m effectively blind to seeing that at my end.
zenspider: I’m not clear what code you’re running. Do you mean that you’re using “basic–2-tutorial.zip” unmodified?
sorry, no. I have implemented all of basic up to the point of implementing the completed colorer, so #lang basic w/ my own main and basic/colorer. Lemme see if I’m fully pushed
@abmclin I started with the current master branch and used hub am (hub is a github-enhanced version of the git command) to add your changes. The effect should be the same as starting with your PR branch and rebasing with the current master branch. (And probably the same as just doing a merge, except without the merge commit.) How is the build failing? Out of memory, or something else?
Ok, I guess I’m actually unclear on how to get into the state you showed. But I also notice that keywords are given the style 'no-color, which seems to mean “don’t change the color” – that is, if “prin” was formerly red to show an error then it won’t be changed to a different color if it becomes part of “print”
that’s exactly the scenario. I can make a video to show it… but put `print” up there, it’ll turn a proper color, backspace once and wait until “prin” goes red, and then type “t”. Only the “t” is black at that point.
sorry to bother you with this. mbutterick isn’t on anything online and doesn’t respond much to my MANY reports against his content
well… damn. I can’t reproduce the red color right now either… I’m gonna have to back up to figure out why/how