64-bit ARM Windows is one of the standard pre-built downloads.
The compiler/demod language integrates demodularization into the
program rather than an external tool. Using the language approach
cooperates with other Racket tools and allows demodularization to be
used on libraries. Additionally, demodularization handles submodules
and can prune definitions, significantly shrinking the size of some
programs.
The contract-in form enables contracts to be specified in an importing
module.
The #%declare form supports the #:flatten-requires and #:unlimited-compile keywords
Identifiers such as case-Ī», match-Ī» and Ī» are equivalent to
their latin-alphabet equivalents (case-lambda, match-lambda, and lambda) in more contexts, including uses of match.
The hash-filter function allows the use of a predicate to select a
sub-table of a hash table.
The module browser can perform filtering on submodules.
The raco test command-line form respects the current-test-invocation-directory parameter, and shows well-formed
module paths in its output.
Racket CS allows the use of in-memory boot files.
The raco/testing collection brings together a variety of testing-
related functions and forms.
This release also includes many bug-fixes and documentation updates!
NOTE: This release (and version 8.13) have a known build problem that
affects the builtpkgs source bundle on Windows. In order to avoid this
problem, use a pre-built bundle or build using a source bundle other
than the "builtpkgs" one. Nightly builds do not suffer from this
problem.
The following people contributed to this release:
Alex Knauth, Alexander Shopov, Ben Greenman, Bert De Ketelaere, Bob
Burger, Bogdan Popa, Cadence Ember, Carl Gay, D. Ben Knoble, Gregory
Rosenblatt, Gustavo Massaccesi, John Clements, John Sullivan, Jordan
Johnson, luistung, Matthew Flatt, Matthias Felleisen, Noah Ma, Philip
McGrath, Robby Findler, Ryan Culpepper, Sam Tobin-Hochstadt, Sergey
Fedorov, Sorawee Porncharoenwase, Wing Hei Chan, and ZhangHao.
Does the first sentence need a verb? (I.e., something like "rather than requiring an external tool", or maybe "into a program without having to run an external tool".) The current version reads as slightly off to me, as though one side of the comparison were "integrates demodularization into ā¦ an external tool". Also, it feels a bit odd to talk about not using "an external tool" but "cooperat[ing] with other Racket tools". But brevity is just about the highest virtue here, even if things have to be slightly fuzzy about how exactly "Racket internalizes extra-linguistic mechanisms".
Nit: Latin-alphabet
Maybe "The contract-in subform for require"? I think someone said something somewhere about being confused that they couldn't just write contract-in on its own. Maybe the answer is that the docs should clarify that enough, though.
I took all of your minor suggestions. WRT your suggestion about the first sentence, I made precisely the same edit as you, and then stared at it a while, and then convinced myself that actually it was correct as sent to me. With the implied duplication of the verb, the existing sentence is saying "The compiler/demod language integrates demodularization into the program rather than [integrating it into] an external tool." ... which I thought was close enough to correct to leave as-is.
But yes, it set off my missing-verb alarm as well. Related question; when using compiler/demod, is the external tool no longer necessary?
Maybe "The contract-in subform for require"? I think someone said something somewhere about being confused that they couldn't just write contract-in on its own. Maybe the answer is that the docs should clarify that enough, though.
What you recall is a discusion of the error message that contract-in issues when used as a stand-alone form. Matthew correctly objected to saying require subform because there could be macros that expand into require (and more). I think Johnās use of āimportā is neutral enough and should stand.
My understandingābut I have not actually used it!āis that you write a module like:
#lang compiler/demod module-path option ...
and its compiled form is equivalent what the raco demod tool would put in module_path_merged.zo for an equivalent module_path and set of options. So, for example, rhombus/rhombus-lib/rhombus/private/amalgam.rkt at 930c0d04c6c3d44297e7c938f918f62314faf40f Ā· racket/rhombus Ā· GitHub can declaratively specify how to demodularize Rhombus' innards, and raco setup, package installation, etc. all work transparently, without requiring a separate build step or committing generated artifacts.
People are more likely to see the announcement if there is an accompanying image.
Does anyone have a suitable image?
I'd like one of the module browser filtering, but will accept any suggestions as right now I have no options.
The module browser can perform filtering on submodules.
Even better if there is both a still and a gif (use screentogif or similar) I can use depending on the context. ( a gif is not appropriate in the blog, but it is for places where it is a short announcement pointing to the blog post)
This looks awesome. @spdegabrielle , do we have a draft of a discourse release announcement? I'm going to post the blog post and un-embargo the download links.
Hmm... interesting. The actual formulation of the original blog post was on the 14th. In general, do y'all think that we should update the date on the blog post to when the blog post actually gets released?
In my mind, the most specific release time is (seconds->date 1723254233); this number appears in the release announcement. For what it's worth. It's not on the 14th either, though, it's back on the 9th.
My understanding of the release process is that the software is usually ready to be distributed weeks before the actual announcement. The announcement blog is also finished and ready to be published weeks before the actual announcement. However, we want to wait until the new documentation is fully built first to give a good user experience, so the announcement is delayed until then. Is my understanding correct?
If so, I think it makes sense that the date we make the announcement is when the software is officially released. It looks that way from users' perspective. They wouldn't know about any of the internal processes, and they shouldn't need to know. And using any other dates from the internal process would be confusing to them.
weeks.... sigh, yes, the evidence supports this. Traditionally, there was only a day or so between bundling and release. I think that waiting for a new doc build is the main holdup at this point. [Edit: which is exactly what you said....]
Anyhow, yes, I think that's obviously correct. I will add an "update the date of the blog post" bullet to my release steps.
