posted by Vincent St-Amour

Racket version 7.0 is now available from http://racket-lang.org/

Racket version 7.0 includes substantial internal changes toward the long-term goal of replacing Racket’s current runtime system and supporting multiple runtime systems. We do not expect Racket users to see a big difference between Racket v6.12 and Racket v7.0, but since the internals differ significantly, a major-version bump helps track the change.

Version 7.0 replaces about 1/8 of the core v6.12 implementation with a new macro expander that bootstraps itself. The expander turns out to be about 40% of the new code needed to replace Racket’s core with Chez Scheme. Most of the other 60% is also implemented, but it is not included in this release; we hope and expect that Racket-on-Chez will be ready for production use later in the v7.x series.

• The syntax (#') form supports new template subforms: ~@ for splicing and ~? for choosing between subtemplates based on whether pattern variables have “absent” value (from an ~optional pattern in syntax-parse, for example). The syntax/parse/experimental/template library, where these features originated, re-exports the new forms under old names for compatibility.

• On Windows, an --embed-dlls flag for raco exe creates a truly standalone, single-file ".exe" that embeds Racket’s DLLs.

• DrRacket’s “Create Executable” option for the teaching language (Beginner Student, etc.) uses --embed-dlls to create single-file, standalone ".exe"s on Windows.

• Typed Racket’s support for prefab structs is significantly improved. This supports using prefab structs more polymorphically, and fixes significant bugs in the current implementation. Programs which currently use predicates for prefab structs on unknown data may need to be revised, since previous versions of Typed Racket allowed potentially buggy programs to type check. See Typed Racket RFC 1 and this blog post for more details on this change and on how to fix programs affected by it.

• Typed Racket supports #:rest-star in the ->* type constructor, which allows function types to specify rest arguments with more complex patterns of types, such as the hash function.

• Interactive overlays can be added to plots produced by plot-snip. This allows constructing interactive plots or displaying additional information when the mouse hovers over the plot area. Examples of how to use this feature can be found here

• racket/plot provides procedures for displaying candlestick charts for use in financial time series analysis.

• Added contract-equivalent?, a way check if two contracts are mutually stronger than each other without the exponential slowdown that two calls to contract-stronger? brings.

• Lazy Racket supports functions with keyword arguments.

The following people contributed to this release:

Adam Davis Lee, Alex Harsányi, Alex Knauth, Alexander McLin, Alexander Shopov, Alexis King, Andrew M. Kent, Asumu Takikawa, Ben Greenman, Caner Derici, Daniel Feltey, David Benoit, David Kempe, Don March, Eric Dobson, evdubs, Foo Chuan Wei, Georges Dupéron, Gustavo Massaccesi, Hashim Muqtadir, Jakub Jirutka, James Bornholt, Jasper Pilgrim, Jay McCarthy, Jens Axel Søgaard, John Clements, Juan Francisco Cantero Hurtado, Kashav Madan, Kieron Hardy, Leandro Facchinetti, Leif Andersen, Luke Lau, Matthew Butterick, Matthew Flatt, Matthias Felleisen, Michael Ballantyne, Michael Burge, Michael Myers, Mike Sperber, Milo Turner, NoCheroot, Oling Cat, Paulo Matos, Philip McGrath, Philippe Meunier, Robby Findler, Ryan Culpepper, Sam Tobin-Hochstadt, Sarah Spall, Shu-Hung You, Sorawee Porncharoenwase, Spencer Florence, Stephen Chang, Tony Garnock-Jones, Tucker DiNapoli, UM4NO, Vincent St-Amour, and William J. Bowman.

Feedback Welcome

posted by Vincent St-Amour

Racket version 6.12 is now available from http://racket-lang.org/

• Changed the way some unsafe operations are exposed via ffi/unsafe libraries to help smooth a future transition to a new runtime system.

• The syntax-parse form supports unwinding side-effects when it backtracks, both explicitly with ~undo patterns and implicitly with the built-in managed state (using syntax-parse-state-ref, etc).

• The db library supports SCRAM-SHA–256 authentication for backends running PostgreSQL 10 or later. Client support for SCRAM and other SASL mechanisms is provided by the new sasl library.

• The lazy-require-syntax form supports lazy loading of macro transformers. Note that the macros must obey certain implementation constraints (see the lazy-require-syntax documentation).

• Typed Racket no longer enforces types like (U String (Boxof String)) with the any/c contract. This fixes a type soundness issue, but may affect performance. Please submit a bug report if you find a program that runs significantly slower on v6.12 than earlier versions.

• Typed Racket’s type instantiation (inst) uses Any for omitted type arguments, allowing APIs to add additional type variables to functions without breaking existing programs.

• for/fold users can customize the final result of a loop’s computation using the #:result keyword.

• The --deps option to raco test tests the packages the argument packages depends on, in addition to testing the packages themselves. For example, raco test -p --deps pkg1 pkg2 tests all files from pkg1, pkg2, and all of their dependencies.

The following people contributed to this release: Alexander Shopov, Alexis King, Andrew Gwozdziewycz, Andrew Kent, Ben Greenman, Chung-chieh Shan, Conor Finegan, Daniel Feltey, Daniel Mendler, Eric Dobson, Gabriel Ebner, Greg Cooper, Greg Hendershott, Gustavo Massaccesi, Huma Zafar, Jack Firth, James Bornholt, Jay McCarthy, John Clements, Kimball Germane, Leif Andersen, Matias Eyzaguirre, Matthew Butterick, Matthew Flatt, Matthias Felleisen, Michael Ballantyne, Mike Sperber, Milo Turner, Robby Findler, Rommel Martinez, Ryan Culpepper, Sam Tobin-Hochstadt, Shu-Hung You, Soulaïmane Sahmi, Spencer Florence, Stephen De Gabrielle, Vincent St-Amour, Wesley Kerfoot, and William G Hatch.

Feedback Welcome

posted by Matthew Flatt with thanks to collaborators Kent Dybvig, Andy Keep, Gustavo Massaccesi, Sarah Spall, Sam Tobin-Hochstadt, and Jon Zeppieri

It’s been almost a year since we decided to try running Racket on Chez Scheme, and it has been almost six months since my last status report. As of RacketCon 2017, DrRacket could start up on Chez Scheme (but just barely, and just in time for the demo).

The current implementation is now considerably more complete. DrRacket still doesn’t run well, but Racket-on-Chez can build a full Racket distribution in reasonable time and space.

With the current Racket-on-Chez compilation strategy, runtime performance is plausible on traditional benchmarks, but cross-module optimization is needed to bring the results fully in line with our expectations. Startup and load times are much slower than we would like. Compile/build times are a factor of 4 slower than the current version of Racket.

Glossary of implementations:

• Racket — the current Racket release, version 6.x

• racket7 — mostly the same as Racket, but using a new, Racket-implemented macro expander; the source is in the https://github.com/racket/racket7 repo

• Chez Scheme — a completely different implementation of Scheme that we’re trying to use as a replacement for part of Racket

• Racket-on-Chez — Chez Scheme plus additional layers to make it implement the same language as Racket; the source is also in the https://github.com/racket/racket7 repo

Approach

Our overall goal is to improve Racket’s implementation and make it more portable to different runtime systems. To a first approximation, improving Racket and making it more portable means “less C code.” Building on a Chez Scheme is a promising means toward that end.

The picture on the right illustrates the current Racket distribution. The parts in blue are implemented in Racket, while the part in red is implemented in C. The green block is Scribble documentation source.   The numbers next to each block are a rough lines-of-code counts, and the blocks are scaled to those counts. The collects block represents the content of the main "collects" directory; along with the core block, it’s roughly the code in a Minimal Racket distribution. The pkgs block is the part of the main distribution that is available in separate packages but bundled with the main distribution. The docs block is spread across the same packages as the pkgs code.   Porting Racket to Chez Scheme is all about the core part. The goal is to make no changes to existing Racket and Scribble code, although we’ll inevitably have to make small changes to support multiple Racket implementations.

Let’s zoom into the core part. (From now on, all the pictures on the right are at this scale.) The picture breaks the C code in Racket’s current implementation into several major subsystems. In reality, the implementation is not organized into such tidy layers, but the picture is conceptually close to the truth.   The large builtins block implements primitive data structures and their operations, such as numbers (fixnums, bignums, flonums, exact rationals, complex numbers), strings, characters, byte strings, lists, vectors, and hash tables. Most other blocks are self-explanatory.   The expander block implements the macro expander, reader, and module system. More than any other part of the current stack, the expander part is better implemented in Racket.

That was exactly the work of 2016: building a new expander to replace the C-implemented expander. You can use that racket7 variant of Racket now by building from the http://github/racket/racket7 repo.   This new expander hasn’t made it into the release, because a few interactions haven’t been sorted out: the macro stepper, the demodularizer, and to some degree the decompiler. The expander also runs at about half the speed of the C-implemented expander, and that performance difference was part of the motivation to investigate a new runtime system.   Although the compiler+JIT block is drawn the same as before in this picture, it’s a slightly different compiler, because it doesn’t know about modules or syntax objects. Instead, the compiler works in terms of linklets, which are lambda-like blocks of code that import and export variables. That separation of expansion/modules from compilation helps enable the transition to a different compiler and runtime system.

And that brings us to Chez Scheme. The most obvious feature in the picture on the right is that Chez Scheme’s C-implemented kernel is a fraction of the implementation, while most of Chez Scheme is more sensibly written in Scheme.   Chez Scheme’s expander is considerably simpler than Racket’s. Although Chez Scheme’s expander is hygienic and hugely influential on Racket’s expander, Racket’s macro and module system does a lot more.   Chez Scheme’s compiler, meanwhile, does a lot more than Racket’s compiler+JIT. The builtins functionality in Chez Scheme is similar to Racket’s builtins.   Chez Scheme’s GC (at the bottom) is tiny and elegant. It lacks some functionality of Racket’s GC, but mostly it lacks Racket’s historical complexity for trying to cooperate directly with C.

That brings us, finally, to the Racket-on-Chez picture. It starts with the Chez Scheme stack and adds a rumble block, which extends Chez Scheme to match the current Racket’s GC through control+structs blocks.   Mostly, rumble is about immutable hash tables, delimited continuations, applicable structures, structure types properties, and impersonators/chaperones. We’ve given this layer of functionality the name Rumble, because it’s useful to have a name for the language that hosts other layers that are built using Racket.   The threads, io, and regexp blocks are entirely new implementations of the corresponding blocks in the current Racket implementation. The rktio block is used by io, and it’s the same as in current Racket: a portability layer over OS facilities that is similar to (but more extensive than) code that is in Chez Scheme’s kernel.

The expander block (the same as for racket7) sits on a small schemify adaptor. The schemify layer converts Racket linklets into plain Scheme functions, adjusting expressions as needed to support applicable structures, to enforce left-to-right evaluation, and to implement Racket’s allocation model for local functions (i.e., lift to avoid closure allocation whenever possible).

Naturally, the Racket-on-Chez implementation is bootstrapped by applying the expander and schemify layers to themselves and the other Racket-implemented parts of the stack, and then compiling the schemified linklets using the Chez Scheme compiler. A thin main driver on top handles command-line arguments to load modules and start the read–eval–print loop.

Current Functionality

DrRacket starts up in Chez Scheme, and just starting DrRacket exercises many Racket language constructs and libraries. The largest Racket-on-Chez demonstration to date is building all of the packages and documentation of the main Racket distribution. Building packages and documentation, again, covers more Racket functionality than you may expect, because our macros do interesting things, such as typechecking and generating bitmap images. Also, the build process is too long and complex to tolerate leaks or major inefficiencies.

Still, many pieces are buggy, and closing the gap is mostly a matter of plowing through the Racket test suites. The main missing or incomplete pieces are: futures, places, and a racket executable that starts Racket-on-Chez.

Performance: Benchmark Sanity Check

The overall compilation story is not yet right in Racket-on-Chez, partly because there’s no cross-module optimization. Functions like map, memq, and assv need cross-module optimization to be compiled well in Racket-on-Chez. Benchmarks sometimes do not rely on cross-module optimization, however, and preliminary benchmark measurements can be useful as a sanity check on the ways that schemify mangles individual modules.

Benchmarks are in the racket-benchmark package whose source is in the racket7 repo. The benchmarks run in Chez Scheme as R6RS libraries. The difference between Racket and racket7 is in the noise.

The table below shows a handful of rough benchmark results. You should not take the results seriously, but they line up with my overall impression of where we are.

		Rough and unscientific benchmark numbers
		msecs		deriv				dynamic				sboyer				maze				nfa
		Chez Scheme		770				360				1270				930				2100
		Racket-on-Chez		1560				1030				1470				1520				2200
		Racket		2030				560				2230				1330				4100

All benchmarks were run in safe mode and without Gustavo’s work-in-progress addition to the Chez Scheme compiler that can eliminate some runtime checks and related dead code.

Performance: Startup

Startup time for Racket-on-Chez is determined by Chez Scheme’s base startup time (to load boot files) plus time to load the expander and other parts of the Racket-on-Chez stack. The load times shown below for racket/base and racket include the startup time and add the additional time needed to load the many compiled files that are parts of those libraries.

For Racket and racket7, bytecode parsing can be delayed at the granularity of a procedure, so that a procedure’s bytecode isn’t parsed until the procedure is called. Delayed parsing is enabled by default, and the -d flag disables it.

		Startup/load time
		msecs		startup				-l racket/base				-l racket
		Racket		16				50				220
		Racket -d		16				80				500
		racket7		50				110				340
		racket7 -d		50				190				650
		Chez Scheme						170
		Racket-on-Chez		440				550				1200
		Racket-on-Chez/JIT		440				550				1600

Compared to the current Racket version, starting up and loading takes longer in racket7, because racket7 has to load embedded bytecode for the expander’s implementation, and because the bytecode encoding of linklets has not been refined as much.

The Chez Scheme row in the table doesn’t actually load racket/base, but that’s the closest reasonable column. That row corresponds to just starting Chez Scheme with its compiler— so it’s a signficantly smaller language than racket/base, but it’s more than the Racket startup rows. It’s also a lower bound on the Racket-on-Chez startup time.

Loading Racket-on-Chez takes significantly longer, still, due to larger and slower-to-load machine code for both the Racket-on-Chez stack and libraries compiled with it. Although individual linklets within a module (roughly, individual phases) are parsed on demand, there is no delayed parsing at the granularity of procedures, so the work performed by loading is closer to the Racket -d and racket7 -d rows.

The last row above, Racket-on-Chez/JIT, refers to a variant of Racket-on-Chez that does not compile whole linklets. Instead, it keeps individual lambdas in source form until called, and it compiles each called lambda on demand. Load times go up, mostly because code is compiled as needed, but also because the source-fragment representation is even larger than machine code right now. The Racket-on-Chez/JIT approach does not look the most promising, so far, but it’s also not crazy. With more effort and tuning (especially in the representation of source fragments), it may be a viable approach and more in line with the way the current Racket implementation works.

Clearly, load time is a direction for further effort.

Performance: Expander and Compiler

The expander runs at about the same speed in Racket-on-Chez and racket7, but the linklet-compilation step takes much longer in Racket-on-Chez. As a result, compilation time for Racket-on-Chez dominates expansion proper for a task like racket -cl racket/base.

Reported times in this section use a Racket-on-Chez stack that is compiled in unsafe mode and run on a 2013 MacBook Pro 2.6GHz Core i5. Unsafe mode improves expand and read performance by about 10%.

		Steps within racket -cl racket/base
		msecs		expand				schemify				compile				eval				read
		racket7		2511								662				235				275
		Racket-on-Chez		2398				917				2852				390				227
		Racket-on-Chez/JIT		2441				974				1044				515				229

For Racket-on-Chez/JIT, compile times go down, showing that about 1/3 of the code that is compiled during expansion is also run during expansion. The fraction would be lower for most programs; the racket/base library is unusual in building up layers of macros to implement itself. The schemify step is certainly a target for improvement, since its job is much simpler than the compile step’s job.

That factor-of-2 slowdown relative to racket7 is compounded by the Racket-implemented expander being twice as slow as the current Racket’s C-implemented expander:

		Loading from source with racket -cl
		msecs		racket/base				racket
		Racket		1830				21700
		racket7		3490				38140
		Racket-on-Chez		7060				70093
		Racket-on-Chez/JIT		5400				55050

The gap between the Racket-implemented expander and the C-implemented expander is the one that we most hoped to close by moving to Chez Scheme. As part of the Racket-on-Chez stack, the expander is already compiled in a reasonable way (i.e., no cross-module optimization issues), so it’s not clear how to improve. Still, I still think the expander can be made to run faster in Chez Scheme, and we’ll keep trying.

Performance: Distribution Build

The current version of Racket-on-Chez builds on a 64-bit machine with a peak memory use around 1.25 GB, which is on a similar scale to the current Racket release’s peak memory use around 1 GB.

The following plots show, on the same scale, memory use over time when building a distribution. Each plot has two black lines (easiest to distinguish in the last plot): the top black line describes peak memory use, since it’s before a major GC, while the bottom black line is closer to live-memory use, since it’s after a major GC. The orange region is for compiling libraries (each vertical line starts a collection), the blue region is for running documentation, the green region is for rendering documentation, and the final pink region is for re-rendering documentation as needed to reach a fix-point for cross references. Memory use is expected to grow modestly during the blue region, since the builds collecting cross-reference information for use in the green region. Memory use should grow minimally in the orange and green regions (as a side-effect of caches).

These graphs report builds on a Linux 3.4GHz Core i7-2600 machine with the Racket parts of the Racket-on-Chez stack compiled in safe mode.

Racket C-implemented expander
racket7 Racket-implemented expander
Racket-on-Chez Same expander as racket7

The plots illustrate that, while memory use is similar, build times are much longer. Expander and compiler performance largely explains the difference.

The build time certainly can be improved some. Maybe build times can be improved significantly, or maybe slower build times will seem worthwhile for a more maintainable implementation of Racket and/or for faster generated code.

Outlook

It would be nice if porting to Chez Scheme made every aspect of Racket magically faster. It hasn’t done that, but we have plenty of room for improvement; the performance results to date are a lower bound on performance, not an upper bound.

Keep in mind that the original goal is not to have a faster Racket, but a better-implemented Racket with acceptable performance. The Racket-on-Chez implementation is far more maintainable and flexible than the current Racket implementation, so maybe we’re half-way there after one year of work.

You can try Racket-on-Chez from https://github.com/racket/racket7/. See racket/src/cs/README.txt in that repo for more information.

If you’re interested in even more implementation details and plans, see the extended version of this report.

posted by Andrew Kent

With the Racket v6.11 release, Typed Racket has begun to support basic refinement and dependent function types. This post gives an overview for working with these types while writing some simple vector operations.

Currently these types are documented under Typed Racket’s experimental features. They are experimental in the sense that they are relatively new. We look forward to improving their usefulness by incorporating user feedback.

Note: If you wish to experiment with refinement and/or dependent function types in the near future, you should use a snapshot build, as it will have additional features and bug fixes from user feedback. Some of the examples in this post will require a build from early November 2017 or later.

posted by Vincent St-Amour

Racket version 6.11 is now available from http://racket-lang.org/

• A bug preventing OneDrive users on Windows 10 Fall Creators update from opening files has been fixed.

• Typed Racket supports refinement types and dependent function types. Previously an experimental feature, refinement types allow types to describe more interesting properties of values, especially integers. For example, this type shows that the max function always produces a number at least as big as its inputs: (-> ([x : Integer] [y : Integer]) (Refine [z : Integer] (and (>= z x) (>= z y))))

• DrRacket’s Program Contour is significantly more efficient; using it no longer hurts DrRacket’s interactivity.

• The web-server/formlets library produces formlets that are serializable, facilitating dynamic uses of formlets in stateless #lang web-server servlets. The new web-server/formlets/stateless and web-server/formlets/unsafe libraries provide additional support with the same API.

• The db library supports the Cassandra database.

The following people contributed to this release: Alex Knauth, Andrew Gwozdziewycz, Andrew Kent, Asumu Takikawa, Ben Greenman, Ben Noordhuis, Carlo Dapor, Daniel Feltey, David Christiansen, David Van Horn, Eric Dobson, Gustavo Massaccesi, Harold Carr, Jack Firth, Jay McCarthy, Jeannie Tran, Jens Axel Søgaard, jgreco, John Clements, Jordan Johnson, Justin Slepak, Leandro Facchinetti, Leif Andersen, Matthew Butterick, Matthew Flatt, Matthias Felleisen, Michael Ballantyne, Milo Turner, Nadeem Abdul Hamid, Philip McGrath, rain, Robby Findler, Royall Spence, Ryan Culpepper, Ryan Davis, Sam Tobin-Hochstadt, Shu-Hung You, Spencer Florence, Stephen Chang, Vincent St-Amour, WarGrey Gyoudmon Ju, and Weng Shiwei.

Feedback Welcome

posted by Stephen Chang

This post is a summary of a tutorial presented at RacketCon 2017.

It describes how to create a package starting from a single Racket file.

Specifically, this post explains how to:

• use raco pkg install to install a package,
• create an info.rkt file containing package metadata, and
• add a package to Racket’s official package catalog.

posted by Ben Greenman, with help from Matthew Butterick and Robby Findler and Jack Firth and Vincent St-Amour and Sam Tobin-Hochstadt

This post describes 3 ways to contribute to Racket: (1) fixing a typo online, (2) submitting a pull request to the racket/racket repository, and (3) submitting a pull request to a repository in the Racket GitHub organization.

posted by Vincent St-Amour

Racket version 6.10.1 is now available from http://racket-lang.org/

Version 6.10.1 patches the recent v6.10 release in three small ways:

• On Linux, corrects a mishandling of file-stream ports that can block on input or output (such as pipes between processes), where closing a blocked port may cause a port that’s opened later to be incorrectly reported as blocked.

• On Windows, corrects a crash in the handling of symbolic links.

• On all platforms, corrects the peer-side results from tcp-addresses.

posted by Vincent St-Amour

Racket version 6.10 is now available from http://racket-lang.org/

Note: Graphical Racket programs such as DrRacket are affected by a bug in the Windows 10 Creators update which can lead to blue screens and require reboots. We are aware of the issue, and have mitigated it in DrRacket, which reduces the incidence of crashes. Microsoft has diagnosed the issue and will release a fix in a future Windows update. Additional details are available here: https://github.com/racket/racket/issues/1671

• Internally, Racket’s intermediate compatibility layer over operating-system facilities has been moved into its own library, “rktio”, so it can be used in future Racket implementations. This change should be transparent, but the refactoring moves code that has many compiler and OS dependencies, so we expect a new glitch or two in less-common build and execution environments. Please report problems at https://github.com/racket/racket/issues.

• Racket supports cross-compilation of executables in more cases, including executables that depend on packages for foreign libraries.

• The struct form supports an #:authentic annotation to declare that chaperones and impersonators are never allowed on instances of the declared structure type. This annotation is intended for use on a library’s internal data structures, where it won’t interfere with contracts or other forms of extension at a library’s interface. It can sometimes provide a small performance boost.

• RackUnit adds nested-info and string-info to grant custom checks more control over the display and layout of check failure info.

• The raco test command provides the ++arg and ++args flags to pass arguments to tested programs.

• Typed Racket has types for immutable, mutable, and weak hashtables; in other words the type (HashTable K V) is a union (U (Immutable-HashTable K V) (Mutable-HashTable K V) (Weak-HashTable K V)). Standard library functions may have more specific return types. For example, hash-set has type (-> (HashTable K V) K V (Immutable-HashTable K V)). When an immutable hashtable flows from untyped code to typed code, Typed Racket may use a flat contract to verify its type (provided the table’s key and value types are flat).

• The Typed Racket Optimizer is disabled in untrusted contexts (e.g., sandboxes). This prevents unsoundness in the Typed Racket type system from being used to get access to unsafe operations.

• Racket’s internal runtime adds a scheme_atexit procedure with identical behavior as atexit defined in libc.

The following people contributed to this release: Alex Knauth, Alexander McLin, Alexis King, Andrew Kent, Ben Greenman, Ben Noordhuis, Carlo Dapor, Conor Finegan, Daniel Feltey, Ethan Estrada, Georges Dupéron, Gary F. Baumgartner, Gianluca Ciccarelli, Gustavo Massaccesi, Harold Carr, Jack Firth, Jay McCarthy, John Clements, Kimball Germane, Leandro Facchinetti, Lehi Toskin, Leif Andersen, Matthew Butterick, Matthew Flatt, Matthias Felleisen, Michael Orlitzky, Milo Turner, Mohsen Keyhani, Philip McGrath, Robby Findler, Rob Bassi, Ryan Culpepper, Sam Caldwell, Sam Tobin-Hochstadt, Scott Moore, Spencer Florence, Stephen Chang, Stephen De Gabrielle, Vincent St-Amour, WarGrey Gyoudmon Ju, and William J. Bowman.

Feedback Welcome

posted by Vincent St-Amour

Racket version 6.9 is now available from http://racket-lang.org/

---

Security Announcement

A security vulnerability in the racket/sandbox library and Typed Racket allowed malicious Typed Racket code to escape the sandbox. This vulnerability has been fixed in Racket version 6.9. Anyone using racket/sandbox to execute untrustworthy code with access to Typed Racket should upgrade to version 6.9 immediately.

While this known vulnerability has been eliminated, it is possible that similar errors in other installed collections could also be exploited, although we are not currently aware of any existing vulnerabilities. We recommend that if you use the Racket sandbox to execute untrustworthy Racket code, you should also employ additional operating system or virtual machine level protections. The documentation for racket/sandbox has been updated to list recommended security practices for using the library.

Thanks to Scott Moore for identifying this vulnerability.

---

• The official package catalog Web site is revised to have a new user experience.

• The Northwestern snapshot site keeps weekly snapshots going up to 12 weeks into the past. Those provide a middle ground for users who want access to new features earlier than stable releases, but want less churn than nightly builds.

• DrRacket provides a refactoring tool to remove unused requires in modules.

• DrRacket’s #lang-line customization support works better with buggy (i.e., in development) languages.

• The web server’s cookie libraries, including “id cookie” authentication, support RFC 6265.

• The db library supports PostgreSQL’s UUID type.

• The raco command lists matching commands when passed an ambiguous command prefix.

• The bytecode compiler detects more optimization opportunities for structure operations.

• Scribble can produce output via XeLaTeX as an alternative to LaTeX.

• Scribble supports the acmart LaTeX style, for use with ACM publications.

• Scribble supports the use of CJK characters in tags.

---

The following people contributed to this release: Alex Knauth, Alexander Shopov, Alexis King, Andrew Kent, Asumu Takikawa, Ben Greenman, Daniel Feltey, David Van Horn, Georges Dupéron, Greg Hendershott, Gustavo Massaccesi, Ingo Blechschmidt, James Bornholt, James Whang, Jay McCarthy, Jeff Shelley, John Clements, Jordan Johnson, Leandro Facchinetti, Leif Andersen, Marc Burns, Matthew Butterick, Matthew Eric Bassett, Matthew Flatt, Matthias Felleisen, Michael Myers, Mike Sperber, Philip McGrath, Philippe Meunier, Robby Findler, Royall Spence, Ryan Culpepper, Sam Caldwell, Sam Tobin-Hochstadt, Shu-Hung You, Spencer Florence, Stephen Chang, Tony Garnock-Jones, Vincent St-Amour, WarGrey Gyoudmon Ju, Wei Tang, and William G Hatch.

Feedback Welcome