04 May 2021

Racket v8.1

posted by John Clements

Racket version 8.1 is now available from https://racket-lang.org/.

  • DrRacket tabs can be dragged, and have new close buttons.

  • Racket CS supports cross-compilation using raco exe.

  • Racket CS supports Android on 32-bit and 64-bit ARM processors.

  • The database library supports running queries in OS threads.

  • Check-Syntax arrows correctly identify the definition site of identifiers with contracts.

  • Racket CS performance has improved for structure predicates and accessors

  • Racket CS is faster at multiplying extremely large numbers and dividing large integers.

  • Racket CS allows callbacks to raise exceptions if they are annotated with #:callback-exns?.

  • New ephemeron hash tables simplify the implementation of tables where keys can refer to values.

  • Typed Racket supports for/foldr.

  • The stepper works for #lang htdp/*sl.

  • Struct signatures work for the ASL teaching language.

The following people contributed to this release:

Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Andrew Mauer-Oats, Anish Athalye, Ben Greenman, Bert De Ketelaere, Bob Burger, Bogdan Popa, Brian Adkins, Cameron Moy, David Van Horn, Dexter Lagan, Dominik Pantůček, Fred Fu, Greg Hendershott, Gustavo Massaccesi, Hazel Levine, Ismael Luceno, Jack Firth, Jarhmander, John Clements, Jörgen Brandt, Laurent Orseau, Lazerbeak12345, Matthew Flatt, Matthias Felleisen, Micah Cantor, Mike Sperber, Noah Ma, Patrick McCarty, Paulo Matos, Pavel Panchekha, Philip McGrath, Philippe Meunier, R. Kent Dybvig, Robby Findler, Ryan Culpepper, Ryan Kramer, Sam Tobin-Hochstadt, Sergiu Ivanov, Shu-Hung You, Sorawee Porncharoenwase, Stephen De Gabrielle, William J. Bowman, bmitc, xxyzz, yjqww6, and ymdarake.

Feedback Welcome!

more →

13 Feb 2021

Racket v8.0

posted by John Clements

Racket version 8.0 is now available from https://racket-lang.org/.

* Racket 8.0 is here!*

Racket 8.0 marks the first release where Racket CS is the default implementation. Creating, polishing, and adopting Racket CS has been a 4-year effort involving the entire Racket community. At this point, Racket CS is faster, easier to maintain and develop, and compatible with existing Racket programs. Racket CS will continue to improve, but at this point it is ready to be the primary variant of Racket for all Racketeers. More details about the current state of Racket CS are available in the recent blog post.

Other notable changes:

  • Racket CS has better parallel garbage collection, a 10%–30% reduction in the size of generated code, and various targeted optimizations.

  • A rewrite of the test-engine package allows the #lang versions of teaching languages to produce linked test-failure messages.

  • The release comes with a new mark-up DSL for composing text to appear in the REPL (simple-tree-text-markup).

  • Redex has an added define-overriding-judgment form and improved error source location reporting.

  • Windows scrolling speed reflects the system preference.

  • The db package uses the utf8mb4 charset for MySQL connections.

The following people contributed to this release:

Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Bert De Ketelaere, Bogdan Popa, Cameron Moy, David Van Horn, Davis Silverman, Dominik Pantůček, Florian Weimer, Fred Fu, Gustavo Massaccesi, Jack Firth, James Wilcox, Joel Dueck, John Clements, Jonathan Chan, Lîm Tsú-thuàn, Mark, Matthew Flatt, Matthias Felleisen, Michael Ballantyne, Mike Sperber, Paulo Matos, Pavel Panchekha, Peter Zhong, Phil Nguyen, Philip McGrath, Robby Findler, Ryan Culpepper, Sam Tobin-Hochstadt, Sergiu Ivanov, Shu-Hung You, Sorawee Porncharoenwase, Stefan Schwarzer, Stephen Chang, Stephen De Gabrielle, Walter H. Yang, WarGrey Gyoudmon Ju, kurinoku, xxyzz, and yjqww6

more →

24 Jan 2021

Racket Compiler and Runtime Status: January 2021

posted by Matthew Flatt

With the upcoming version 8.0 release, Racket on Chez Scheme (Racket CS) will become the default implementation of Racket. This report discusses the implications of that change, continuing a series that was originally about Racket CS; the most recent previous report was the February 2020 report. The original January 2018 report explains the motivation behind throwing out around 200k lines of C code to replace it with around 150k lines of Scheme and Racket code.

Switching to Racket CS

For most users, the differences between Racket CS and Racket BC (“before Chez”) may be too small to notice. The installer and executables will be larger, because they contain machine code instead of bytecode, and some programs may run a little faster. Otherwise, Racket programs are supposed to run the same.

To test this, we’ve built and tested every package available from the package server on Racket CS over the past several months and compared the results with those from Racket BC version 7.9. Out of more than 1800 packages, currently only 12 now fail to compile, and 5 others fail some of their tests. The new build failures, as well as 2 of the 5 new test failures, are the result of changes at the C API level. Several packages already have pull requests to fix them, and we hope others will be fixed soon, too. The remaining 3 test failures are differences in thread scheduling that provoked existing bugs in the packages.

Although Racket CS will be the default for v8.0, Racket BC will remain available through a “More Installers” link on the download page for the foreseeable future. So, Racket users will still have the option of falling back to the old runtime system and compiler if something goes wrong, or if they need a package that does not yet work on Racket CS.

Progress in the Past Year

During 2020, Racket CS became a little faster and a little smaller, and many corners of the implementation were repaired or made more compatible with the BC implementation. The planned changes that were on the previous report’s roadmap all happened! In addition, we introduced an AArch64 backend and ported to run natively on M1 Macs. Finally, we made the Chez Scheme garbage collector run in parallel, which brought the performance of places-based parallelism in Racket CS about on par with BC.

Building Racket CS no longer involves first building Racket BC as a way to bootstrap Chez Scheme. Instead, Chez Scheme bootstraps itself on any supported platform using a new portable bytecode (pb) backend. Bootfiles for pb mode are checked into a separate Git repository that is used in a submodule-like way, but bootfiles can always be built from source by using an existing Racket build; the bootstrap implementation is now detangled so that much older Racket versions in the v7 series can work for bootstrapping.

Benchmark Performance

For traditional Scheme benchmarks, not much has changed in the results. A plot is practically indistinguishable from the one in the previous report.

For the shootout benchmarks, which measure more Racket-specific functionality and libraries, there’s some improvement, especially toward the end of the table. (Shorter is better.) The light-blue line shows the results from the previous report (which corresponds to version 7.6), so a shorter “CS” bar means improvement there. The improvements mostly reflect unboxed floating-point arithmetic.

Below is another set of microbenchmarks from the racket-benchmarks package, comparing Racket CS to BC. Some points to note:

  • CS is usually faster than BC. (Shorter is better.)

  • The fastest relative CS runs are much faster than the fastest relative BC runs; that is, the shortest blue bars are much shorter than the shortest red bars. Although it’s difficult to extract from these plots, the difference is really that CS performs more consistently, so it’s slowest relative runs are not as slow as the slowest relative BC runs.

  • These benchmarks mostly compare subsystems that are implemented in C for BC to subsystems implemented in Scheme and Racket for CS. That’s the key and motivating point — the maintenance advantage, more than the performance advantage.

For the rest of this report, the plots will show CS slower or bigger, but gradually approaching BC performance. You should not read that as “CS is slower than BC.” This report is about the parts of the implementation where we spent time last year, and we don’t dwell on parts where no improvement was needed.

About the measurements: Benchmarks are in the "racket-benchmark" package in the "shootout", "control", "hash", and "chaperone" directories. We dropped some of the "control" benchmarks because they take to long to run on BC, which means that the plots here understate how much more consistently CS performs compared to BC.

Startup and Memory Use

Load times improved for Racket CS:

That’s mostly due to reduced code size:

On a different scale and measuring peak memory use instead of final memory use for DrRacket start up and exit:

The large drop in peak memory use for DrRacket CS is due to garbage-collection improvements for old generations in large heaps, where old-generation objects tend to be marked in place instead of copied.

About the measurements: These results were gathered by running racket with the arguments -l racket or -l drracket. The command further included -W "debug@GC" -e (collect-garbage) -e (collect-garbage), and reported sizes are based on the logged memory use before the second collection. For the “BC” line, the reported memory use includes the first number that is printed by logging in square brackets, which is the memory occupied by code outside of the garbage collector’s directly managed space. Baseline memory use was measured by setting the PLT_GCS_ON_EXIT environment variable and running with -n, which is has the same effect as -e '(collect-garbage)' -e '(collect-garbage)'. DrRacket was initialized with racket/base as the default language; also, background expansion was disabled, because measuring memory use is tricky on Racket BC.

Build Times

Compile times improved for Racket CS:

This improvement, combined with others, makes the CS distribution now build a little faster from source than a BC build, and it uses about 20% less memory than the BC build. The following two plots use the same scale, where the foreground blue or red line shows memory use (vertical) plotted over time (horizontal) as recorded on each major collection (see this page for a detailed description):

Racket CS



Racket BC


A shorter build time in less space represents a big milestone for Racket CS. Even though most Racket users start with a pre-built distribution, build time measures end-to-end performance across many parts of the implementation, and build performance correlates well with end-to-end performance in many Racket applications.

The build plots above are for a sequential (i.e., single-threaded) build. More typically, Racket is built on machines with more CPUs, and build times easily benefit from process-like parallelism. Over the past year, garbage-collector improvements for parallel collection have made build times with place-based parallelism dramatically shorter on a machine with 4 hyperthreaded cores (although build dependencies ultimately limit parallelism). Since parallel collection debuted in Racket CS v7.9 but has improved since, we show v7.9 as an intermediate point:

As the plot shows, as of the previous report (before parallel garbage collection), trying to build with multiple places was counterproductive. The speedup from places-based parallelism in v8.0 is finally close to BC’s speedup, which is about the same as using process-based parallelism (but with the advantage of staying within a single Racket process). The parallelism available from BC remains a little higher, because its implementation of places uses completely separate allocation heaps, while parallelism in CS use a single heap.

About the measurements: The compile-time results were gathered by using time in a shell a few times and taking the median. The build plots were generated using the "plt-build-plot" package, which drives a build from source and plots the results. The parallelism results were generated by starting with an in-place installation, using raco setup fast-clean and rm doc/docindex.sqlite to start from a clean state, and getting elapsed real time with time racro setup jobs 8, and dividing by elapsed time from build plots (which is not exactly the same build job, but is close).

Reflection and Outlook

We tried to declare success and move on a year ago, but that didn’t work. This time really is different, because Racket CS is ready to be the default Racket implementation. Time will tell whether that difference is enough to allow a different focus in the coming year. Given how much the CS compilation strategy (ahead-of-time) differs from the BC strategy (bytecode compilation plus a JIT), it’s not clear that the compile time, load time, and memory footprint differences between BC and CS can be reduced further.

In terms of maintainability, one possible direction for improvement is to shift even more Racket support into the Chez Scheme layer. Gustavo’s decision to implement type reconstruction as a Chez Scheme pass was good call. Contributor yjqww6’s implementation of Racket-style lifting as a Chez Scheme pass was a clear improvement for Racket CS, because it eliminated a larger pass on the “schemify” side and implemented at a better layer of abstraction with less interference on local optimizations. Similarly, extending Chez Scheme’s support for weak hash tables, which was not difficult, allowed us to discard a complex and slower implementation in the “rumble” Racket-adapter layer. More direct support for left-to-right evaluation guarantees and cross-linklet inlining could further reduce the schemify layer, and maybe one day eliminate it.

We’ve mostly kept BC and CS in sync, so far, but moving forward, Racket BC will not necessarily get new functionality that is added to CS. After all, the point of CS is to eventually shed technical debt in BC. This divergence has already started: Racket CS fully supports M1 Macs, but Racket BC runs only in interpreted mode or as x86_64 (i.e., we did not add an AArch64 JIT to Racket BC).

Thanks to Sam, Ryan, Robby, Matthias, and John for improving this report. Special thanks to Sam, Paulo, and Robby for moving CS testing forward. Many contributors helped track down and repair CS bugs, and besides others mentioned, thanks to Shu-Hung, Sorawee, and Bogdan for tackling some substantial repairs.

more →

02 Nov 2020

Racket v7.9

Racket version 7.9 is now available from https://racket-lang.org/

  • Racket CS may become the default Racket implementation in the next release. If, between this release and the next, no bugs are discovered in Racket CS that are more serious than those typically discovered in Racket BC, then Racket CS will become the default for the next release. (Serious Racket CS bugs were found since the v7.8 release, but they’re ever fewer and farther between.)

  • Various improvements to Check Syntax arrows and renaming, thanks to Sorawee Porncharoenwase.

  • Full support for struct type properties in Typed Racket, developed by Fred Fu.

  • Racket CS now supports parallel garbage collection, along with improvements for place-local-allocation and incremental promotion.

  • Unix platforms now use the XDG filesystem conventions for the locations of per-user configuration and library files by default, but legacy paths are still used where they exist already.

  • Scribble improvements by Sorawee Porncharoenwase, William Bowman, and Shu-Hung You.

  • Improvements to the plot library from Alex Harsányi and Bert De Ketelaere.

  • The datum form from syntax/datum works with syntax pattern variables and syntax-parse attributes.

  • Unicode input works with recent versions of libedit in addition to libreadline. On Mac OS, a compatible version of libedit is included with Racket.

The following people contributed to this release:

5pyd3r, A. Green, Adam Michael, Alex Bartholomew, Alex Harsányi, Alex Knauth, Alexander B. McLin, Alexander Shopov, Alexis King, Andrew Mauer-Oats, Andy Keep, Ayman Osman, Barak A. Pearlmutter, Ben Greenman, Bert De Ketelaere, Bob Burger, Bodie Solomon, Bogdan Popa, Bruce Mitchener, Chris Frisz, Christian Häggström, Cullen Jennings, Daniel Brunner, DeathKing, Dionna Amalie Glaze, Dominik Pantůček, Evan Minsk, Fred Fu, Gavin Whelan, Graham Watt, Griffin Byatt, Gustavo Massaccesi, Göran Weinholt, Jack Firth, Jamie Taylor, Jason Felice, Jason Hemann, Jasper Pilgrim, Jay McCarthy, Jesse Alama, Jin-Ho King, John Clements, Jon Zeppieri, Juan Francisco Cantero Hurtado, Jéssica Milaré, Jörgen Brandt, Laurent Orseau, Leo Uino, Matthew D. Miller, Matthew Flatt, Matthias Felleisen, Michael Lenaghan, Mike Sperber, Mohamed Akram, Neal Alexander, Nick Fitzgerald, Oscar Waddell, Paulo Matos, Pavel Panchekha, Peter Klein, Philip McGrath, Quentin Dufour, R. Kent Dybvig, Robby Findler, Ryan Culpepper, Sam Tobin-Hochstadt, Shu-Hung You, Sorawee Porncharoenwase, Stephen Chang, Stephen De Gabrielle, Steven Watson, Taekyung, Ted Lemon, Thorsten Blum, Virgil Hou, William J. Bowman, combinatorylogic, deeglaze, evdubs, john, tokomikea, xxyzz, yjqww6, 陈梓 立, and 靈

more →

06 Oct 2020

(chaperone (tenth RacketCon))

posted by Matthew Flatt

RacketCon is next week!

Naturally, RacketCon is virtual this year. So, the bad news is that we don’t get to be in the same room. The good news is that no one has to travel across the country or around the world to attend. RacketCon is open to all with no registration required.

Even in virtual mode, we don’t have to completely give up on social events. Instead of our typical brewpub gathering, we’ll have a BYOB virtual Biergarten via Gather on Friday, October 16 at 6:00pm UTC. That’s 2:00pm Eastern and only noon in the Mountain time zone where I’ll be — but, hey, it’s Friday.

Talks start on Saturday at 2:00pm UTC, which is 10:00am Eastern and 7:00am Pacific. (Note that the schedule on the RacketCon page will adapt to your local timezone.) Kathi Fisler is our keynote speaker, and we’ll also hear talk from Chris Webber, Konrad Hinsen, Brian Adkins, Sage Gerard, Pierce Darragh, Gustavo Massaccesi. In each case, there will be a pre-recorded talk video followed by a live Q&A with the speakers and further Q&A in the chat channels.

On Sunday, Sam Tobin-Hochstadt will talk about the State of Racket, followed by the Racket Town Hall. Then it’s more talks from Jesse Alama, Peter Zhong, Panicz Godek, Stephen De Gabrielle, and Ben Greenman, and finally an AMA with Matthias Felleisen.

The talks are scheduled with a lot of time in between, so hop back over to Gather during those breaks to chat more with other Racketeers.

more →

03 Aug 2020

Racket v7.8

Racket version 7.8 is now available from https://racket-lang.org/

  • Racket CS may become the default Racket implementation in the next release. With the improvements in this release, Racket CS provides all of the functionality of Racket BC (the current default implementation). If, between this release and the next, no bugs are discovered in Racket CS that are more serious than those typically discovered in Racket BC, then Racket CS will become the default for the next release.

  • Racket CS supports AArch32 and AArch64, including places and futures. The implementation should be considered experimental in this initial release.

  • Racket CS supports an “incremental” garbage-collection mode that can eliminate long GC pauses for some applications, such as animations and interactive games.

  • Racket CS unboxes local floating-point arithmetic (like Racket BC).

  • DrRacket’s spell check features lower overhead and has fewer bugs.

  • Web Server performance under high concurrency is better by up to an order of magnitude. The Web Server is also more resistant to clients attempting to use unconstrained resources.

  • The math library includes the Kronecker product.

  • Windows supports finer granularity for sleep when sleeping for short periods of time, improving performance in animation.

  • The new prop:struct-field-info property provides static information about field names.

  • Debugging context in Racket CS is limited to 64,000 frames (approximately the same as Racket BC). This reduces the time taken to handle out-of-memory failures.

  • In plot, the legend font and the plot font can be controlled independently, and error-bars have an #:invert? option.

  • The plot and math libraries have new maintainers: Alex Harsányi for plot and Pavel Pancheka and Jens Axel Søgaard for math.

The following people contributed to this release:

Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Andrew Kent, Andrew Mauer-Oats, Atharva Raykar, Ben Greenman, Benjamin Yeung, Bert De Ketelaere, Bogdan Popa, David Christiansen, David Florness, Diego Crespo, Dionna Amalie Glaze, Fred Fu, Gary Baumgartner, Georges Dupéron, Gustavo Massaccesi, Jack Firth, Jay McCarthy, Jens Axel Søgaard, Jesse Alama, John Clements, Laurent Orseau, Leif Andersen, Luka Hadži-Đokić, Marc, Matthew Butterick, Matthew Flatt, Matthew Parris, Matthew Turland, Matthias Felleisen, Michael Ballantyne, Mike Sperber, Noah W M, Paulo Matos, Pavel Panchekha, Philip McGrath, Raphael Das Gupta, Reuben Thomas, Ricardo Herdt, Robby Findler, Ryan Culpepper, Sam Tobin-Hochstadt, Sancho McCann, Sorawee Porncharoenwase, Spencer Florence, Stephen De Gabrielle, Syntacticlosure, Tim Brown, Yury Bulka, frogbird, kryptine, rsiddharth

more →

23 Jun 2020

Racket Survey 2020

posted by Stephen De Gabrielle and Sam Tobin-Hochstadt

We’re taking a survey! We want to better understand the Racket community, from people who have been contributing for decades to those who have just joined us, and from seasoned programmers to those just starting out.

One of our goals is to help bring in new contributors and make it easier to become a part of the community.

Fill out the survey here: https://forms.gle/XeHdgv8R7o2VjBbF9

more →

10 May 2020

Racket is 25

posted by Matthias Felleisen and Matthew Flatt

The First Thoughts [Matthias]

Wednesday 25 January 1995

POPL used to be a Monday-through-Wednesday-noon affair. Cormac Flanagan presented his future paper there (a static analysis on how to eliminate implicit touch operations; there was also the infamous Felleisen-Wadler paper). Wednesday night, Cormac and I were flying back to Houston. On this flight back Cormac asked a seemingly simple question:

If functional programming is that good, why is nobody using it?

We spent the entire flight discussing this from various angles. My experience with helping my son’s algebra teacher and, years earlier, a baby sitter with algebra homework, pushed me in the direction of “algebra is functional programming and we can make a huge difference by bringing math alive.” We arrived late in the evening, and when I got home, I sent email that we’d have a meeting next morning.

Thursday 26 January 1995

We all met in Corky Cartwright’s office because it was bigger than mine. I announced that I wanted to leave theory behind and build a curriculum, a programming language, and support software to use functional programming for teaching algebra, more math, and programming in K-12 schools.

Shriram embraced the idea on the spot. “I have always wanted to be involved in such a project.” Bruce loved the chance to design a new language. Cormac made clear he’d help but he really wanted a dissertation. Matthew was quiet. Corky later dismissed the idea. “Make sure you have path back when it fails.”

We discussed for quite a while and came to two conclusions: the PhD students needed to focus on software issues for dissertations in case we’d fail. Bruce and I would focus on the language and the curriculum.

Friday 27 January 1995

Bruce and I started designing a language called Jam. It was supposed to be simple, Scheme-ish, and without parentheses because we were convinced that teachers would not like the parenthetical notation. At the same time, we were sure that the syntax should be basically “parenthetically simple.” But most importantly, we wanted to have image-like parts in this language so that Sum, Integral, Indexing, and so on would look as much as possible like the math text books.

In parallel, all of us discussed that we’d use Scheme to build this software ecosystem.

Saturday 28 January 1995

A few weeks later I found out that over this weekend Matthew had started to “cobbled together MrEd.” I am sure he didn’t use “cobble” but something close. And it probably took a bit more than this weekend. What I am pretty sure about is that the first key strokes of conception probably took place on that day (cross-producting my memory with my understanding of Matthew).

The First Keystrokes [Matthew]

I don’t remember the different meetings. Maybe it was the second meeting where I suggested the current user interface— Emacs and the command line— was the biggest obstacle for students.

In any case, I set out to build a user-friendly environment. The main problem, it seemed at the time, was to build a GUI text editor that could handle modern entities like pictures and live objects. I picked wxWindows as a starting point, because it seemed like the most promising cross-platform GUI library, and libscheme as the Scheme implementation, because it was easy to embed. I figured that the hard part of a text editor was making it run fast enough, so I wrote that part in C++.

The program was called “MrEd” because it was mostly an editor. The name “ed” was already taken. Among the words you get by adding a letter to the front, only “red” was appealing for whatever reason, but that name was also taken (as “restricted ed”). Adding one more letter arrived at “mred.” I liked the “Mr” part and didn’t mind that it was already the name of a talking horse.

Although the editor core was in C++, I at least knew enough or had enough direction from the group to aim for Scheme for the rest of the environment’s implementation. So, libscheme became not only the vehicle for running student programs, but also the language for implementing much of the GUI itself. To make that practical, I started changing libscheme: adding a built-in object system that supports extension of C++ classes, adding compilation to an AST instead of interpreting S-expressions directly, and so on. After a few months, I became attached enough to this part of the implementation to break it out as a separate piece. I called it "Ms. Scheme", but since "Ms" seemed too likely to suggest "Microsoft", spelled it "MzScheme". (Around 2001, we started using the umbrella name "PLT Scheme" and moved away from adopting cute names for subsystems. "PLT Scheme" became "Racket" in 2010.)

That’s why the oldest entry for HISTORY.txt in the gui-lib package is “Version 0.7: May 10, 1995,” while the oldest entry in HISTORY.txt for the racket collection is “Verion 0.27: September 26, 1995.” The editor came first, and the language was something of an afterthought.

Of course, the language quickly came to dominate the idea— if not the day-to-day work, which for several years was still mostly about getting cross-platform GUI and drawing toolkit to run well. Given that the language became the main line of the project, it’s easy to see choices that would have been a better starting point, even in 1995. But it turned out okay.

The First Users [Matthias]

By summer ’95, I had designed the basics of what is now known as the design recipe and a few days worth of teaching material. We recruited four teachers and one of Corky’s PhD candidates to test this material with a week-long workshop.

I started with Chez Scheme and Emacs.

During the week, Matthew demoed a rudimentary IDE based on MrEd. I was suitably impressed and tried MrEd on the four participants, with simple images and all. It didn’t go too well, but we had the first four innocent users try out our very first teaching environment.

And that’s how Racket launched.

more →

02 May 2020

Racket v7.7

posted by John Clements

Racket version 7.7 is now available from https://racket-lang.org/.

  • Racket CS remains ready for production use—thanks to those who have been putting it into practice to help iron out the remaining kinks—and it now supports a C API for embedding into other applications. See the “Inside: Racket” documentation for details.

  • Racket CS uses a new HAMT implementation, dramatically reducing the memory required for immutable hash tables.

  • Optimizations to the Racket CS compiler result in a code size savings of approximately 20%.

  • GC callbacks are reliably called on major collections in Racket CS. Also, garbage collection is 10–20% faster.

  • DrRacket can recover much more quickly from errors involving large stack traces.

  • DrRacket now supports the use of the keyboard in the macOS Catalina “Open File” dialog.

  • The net/http-client collection supports the deflate content encoding.

  • The call-in-continuation function (like Marc Feeley’s continuation-graft) simplifies certain call/cc patterns by calling a thunk in a restored continuation.

  • The call-with-current-language form allows more reliable tests for language level code.

  • Use of the Cairo library can be multi-threaded.

  • Improved documentation!

  • Many bug fixes!

Contributors: Alexander Shopov, Ben Greenman, Benjamin Yeung, Brian Adkins, Brian Wignall, Chongkai Zhu, Craig Ferry, David Florness, Fred Fu, Greg Hendershott, Gustavo Massaccesi, Ilnar Salimzianov, Jack Firth, James Bornholt, Jay McCarthy, Jens Axel Søgaard, Jesse Alama, John Clements, Jon Zeppieri, Kartik Singhal, Laurent Orseau, Leo Shen, Luka Hadži-Đokić, Matthew Butterick, Matthew Flatt, Matthias Felleisen, Mike Sperber, Noah W M, Paulo Matos, Philip McGrath, Philippe Meunier, Ricardo Herdt, Robby Findler, Ryan Culpepper, Sam Tobin-Hochstadt, Sorawee Porncharoenwase, Spencer Florence, Stephen Chang, Syntacticlosure, Thaddäus Töppen, Tom Gillespie, Xu Chunyang, ZHUO Qingliang, kryptine, mehlon, muzimuzhi, redwyn, and Štěpán Němec

more →

30 Mar 2020

Running a pkg-build today

posted by Ben Greenman, Alex Knauth, and Fred Fu

Suppose you’ve made a change to Racket and want to test it against all packages in the main catalog. The pkg-build package can help, provided you have: (1) a modified version of Racket and (2) a sandbox VM to build packages on. This post explains how to meet these requirements.

more →

Made with Frog, a static-blog generator written in Racket.
Source code for this blog.