my sense is that raco test is very slow on windows. Does anyone know if this is true and why it would be?
Should I just be using WSL? (In which case I have to figure out how to manage the X11 dependencies…)
Not a real answer just an unqualified guess: if raco test does a lot of forking/spawning processes this is notoriously slow on windows
I have a redex question. I have various metafunctions that have missing cases where I expect the machine to “get stuck”. This results in exceptions. I’d like to write tests for those cases, but I’m not sure how. Am I “doing it wrong”? Should I be moving all those cases to where clauses in the small step semantics? And, if I did so, I guess the way to write tests would be to use the “transitive reduce” function and see what state it winds up in? I imagine I’d be ok with writing a test that a given reduction fails with an exception, too, unless that’s going to get me in trouble later. It is useful, I imagine, to be able to distinguish “missing case I probably want to add” from “intentionally missing”, which right now I cannot.
Same for frequent small file access operations.
Maybe there’s a better solution, but my guess is that you should check the metafunction’s precondition before you try to apply it (in the reduction relation, for example, by using a where or side-condition clause). Or perhaps instead of a metafunction you should formulate it as an IO-mode judgment instead and use a where clause to “apply” it and extract the result. You could also combine these ideas by making an IO judgment that internally checks the precondition and uses the existing metafunction as a helper.
I think I’ve seen that on Windows, fortunately not often. Similar to what @massung recommended, I went to the task bar icon, hovered over it, a mini-window appeared above, and then I right-clicked in its upper-left corner to select “Move,” as below.
I have 2 external monitors attached to my work laptop, one of them 4K, and I think sometimes Windows loses track of where a window is, as in, it almost seems to put a window on a 4th monitor that doesn’t exist and never did, or it banishes a window beyond city limits.
raco test has quite a few options. Some of which I wouldn’t expect to be much slower on Windows than using racket on the same file? Others might be, like the ones that run each test in its own process?? What’s an example invocation of how you’re using raco test?
Also for programs with non-trivial macros raco make will do the expansion once and save it, making both racket and raco test potentially much faster. So idk if you’re doing raco make repeatedly on the same file or something like that.
(But I wouldn’t expect raco make to help more on Windows than on Linux or macOS, so I don’t know if that’s relevant to your question.)
Interesting, looking at GitHub Actions logs for Racket Mode, it seems the Windows tests take ~3 minutes whereas Ubuntu is ~2 mins.
(However that’s a mix of Racket and Emacs tests; it’s timing a single make test, as opposed to the CI job having single make test-racket and make test-elisp steps. Maybe I could try the latter sometime).
Anyway idk if that’s on the order of how much slower you’re seeing your tests run on Windows vs. whatever else you’re comparing?
Is it possible to include a literal expression in the pattern of a syntax-parse expression? (syntax-parse #'(a (b (c d)) e)
[(v1:id (~literal-expression (b (c d))) v2:id)
#'(v1 v2)])
; -> #'(a e) Something similar to this?
Try ~datum
@gknauth That happens for other applications as well?
racket/gui or DrRacket can check the size of the screen and the window position stored in the preference file during startup. But if the screen size reported by the OS (via (get-display-size)) is for a disconnected external monitor, I can’t see a way to fix the issue.
I think it’s not announced yet
Aha! Thank you very much!
@shu—hung I was just guessing at what might be happening. Basically, when you hover over the icon of an application that is being treated this way by Windows, you don’t see the filled in outline of the missing window, you see a hollowed-out, ghostly outline of the window, such that if you click on it, nothing appears, but if you right click on the upper left corner of the ghostly mini-window, sometimes you can use Move to bring it from the netherworld back into our world.
Okay. Sounds even trickier than I thought :disappointed:
Has anyone seen the following error in DrR 8.2 on Windows? From a student: using Check Syntax with an empty DrRacket window (I’m pretty sure the student was in ISL at the time) results in a command-prompt window complaining > namespace-attach-module: a different declaration is already in the destination namespace > module name: #<resolved-module-path: “C\Program Files\Racket\collects\racket\class.rkt”>
Yes! Thanks for forwarding this message. The error message will go away in v8.3. At the moment, Check Syntax should still be functioning despite that message
FWIW there were some discussions in https://github.com/racket/htdp/issues/155
thanks :slightly_smiling_face:
Racket News has hit the newsstands https://racket-news.com/2021/10/racket-news-issue-54.html :racket-news:
Is there a method for storing compiled files (.zo files) in named directories (say, according to the Racket version)? We have a CI/CD machine and we’ve upgrade Racket on it, but the old versioned .zo files stick around. If we could put the .zo files in (and use them from) a new location that would make the process easier.
Not that I know of. If there is a way, I am interested too.
Don’t know if people saw this link for workarounds: https://www.technipages.com/bring-off-screen-window-back-onto-screen
One thing that is probably worth checking what get-display-count reutrns and then calling get-display-size with all of the numbers up to the count, just to see if they are sensible.
You can set PLTCOMPILEDROOTS to something that includes @(version).
Branching for the 8.3 release is planned for 23:00 UT today (2021–10–07)
Ah, I remember this now
Yes, I think we added that for you… :slightly_smiling_face:
blast from the past https://lists.racket-lang.org/dev/archive/2012-October/010527.html
Maybe Greenwich can have GMT and UTC can just be Utah Time.
You know why UTC is neither CUT (coordinated universal time) nor TUC (temps universel coordonné), don’t you?
Um… no? But do notice that I didn’t say UTC, I said UT (probably should have said UT1). So that could be off by as much as 0.9 seconds. Do you want to join me for Frank Reed’s class on Lunars?
Random github question. Does anyone know why the list of all htdp issues at <https://github.com/racket/htdp/issues?q=> (both open and closed) doesn’t include <https://github.com/racket/htdp/issues/158> ? It’s weird.
I think, it’s the order. If you sort by “recently updated” it appears.
But … Hmm. That doesn’t explain why it is missing from the default order.
It was created a long time ago
Also doesnt show in just the closed list, very odd
sometimes when i open drracket, the entire x11 server crashes on my desktop….. it’s rare but it’s been happening a few times. does anyone else have this problem with drracket on linux ? any logs that i can send to help? I think its tied to setting the language to BSL manually
The real question is, how did it get assigned that number
^I had that thought too, why is it such a large number if it’s that old?
Oh… I moved it over from racket/racket. So I just foolishly assumed that the ordering was by number. Thanks!
I’m totally surprised by that as well!
The release process for v8.3 has begun: release checkpoints have been created for all packages in the main distribution, and release branches have been created when necessary. You can go on using master branches as usual. The main Racket repo’s is now bumped to v8.3.0.1 (to avoid having two different trees with the same version).
If you have any bug-fixes and changes (including history updates) that need to go in the release then make sure to specify that in the commit message by using the word merge or release or mail the relevant repo manager [1]) the commit SHA1s. Do not push commits directly to release branches.
Please make sure that code that you’re responsible for is as stable as possible, and let me know if there is any new work that should not be included in this release.
>>> NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT <<<The time between now and the end of the merge window is for fixing new errors that prevent proper functioning of major components and that show up during the preparation for a release. You can also finalize piece of work that is not yet complete, but please avoid merging new features.
Note that nightly builds will go on as usual (starting from v8.3.0.1 and going up as usual), and pre-release builds will be available shortly at
https://pre-release.racket-lang.org/
Please tell me if you think that this release is significant enough that it should be announced on the users list for wider testing.
[1] https://github.com/racket/racket/wiki/release-repo-managers
Upcoming dates: – 15th: Merge window ends, testing starts – 22nd: Testing ends
related question for the Kids These Days: where should messages like this be posted? I mean, yes I’m posting it to the racket-dev mailing list, but where would it go on slack? I could put it in the “release” channel, but I feel like there are tons of channels where no one will ever see anything.
Yep, I think you’re right.
oops