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 →

19 Feb 2020

Racket-on-Chez Status: February 2020

posted by Matthew Flatt

For background information about Racket on Chez Scheme (a.k.a. Racket CS), see the original announcement, the January 2018 report, the report at Scheme Workshop 2018, the January 2019 report, the ICFP experience report, and the report at RacketCon 2019.

Racket on Chez Scheme (Racket CS) is ready for production use. Racket CS now passes all of the tests for the main Racket distribution tests, and differences in compile and run times are much reduced. Overall, Racket CS tends to perform about the same as the traditional Racket implementation (Racket BC, “before Chez”)— sometimes better and sometimes worse, but typically using more memory due to larger code sizes.

Racket CS is not yet the default Racket implementation, but it is available as a download option alongside the regular Racket release at https://download.racket-lang.org/ (select CS from the Variant popup).

Run-Time Performance

Run-time performance for Racket CS has continued to improve. Benchmarks show the difference to some degree, but they understate the difference for a typical Racket application. Alex Harsanyi shared his initial experience with Racket CS in December 2018, and he has been kind enough to keep taking measurements. The plots below show his results for Racket CS and Racket BC, where lower is better, and the overall trend here seems typical for applications that I’ve measured.

As the trend lines may suggest, the overall improvement is from many small changes that add up. The plateau around June to October 2019 coincides with a push on correctness and compatibility, as opposed to performance, to make all Racket tests pass.

The plots below show current results for traditional Scheme benchmarks. The top bar is current and unmodified Chez Scheme, while the second bar is Chez Scheme as modified to support Racket. The third bar is Racket CS, and the bottom bar is Racket BC. The last two rows of benchmarks rely on mutable pairs, so they are run in Racket as #lang r5rs programs. There’s not a lot of difference here compared to one year ago, except that a faster path for integer division in the Racket variant of Chez Scheme has eliminated the collatz outlier.

The next set of plots compare Racket CS and Racket BC for Racket-specific implementations over years for The Computer Language Benchmarks Game. Compared to one year ago, the fraction of benchmarks where Racket CS wins over Racket BC is reversed. Much of that improvement happened in the thread and I/O layers that were newly implemented for Racket CS.

About the measurements: Alex Harsanyi’s measurements are for parts of the ActivityLog2 test suite; ActivityLog2 and the CI infrastructure it runs on have both changed over time, so the plots are approximate, but they are generally consistent with fresh runs with the current ActivitlyLog2 implementation on Racket versions 7.3 through All other measurements use a Core i7-2600 at 3.4GHz running 64-bit Linux. Benchmarks are in the "racket-benchmark" package in the "common" and "shootout" directories. We used commit a20e3f305c of the Racket variant of Chez Scheme and commit cdd0659438 of Racket.

Startup and Load Times

Load times have improved for Racket CS. Loading the racket/base library:

Loading the full racket library:

Load times are, of course, directly related to memory use, and Racket CS load times improved primarily through reduced memory use.

About the measurements: These results were gathered by using time in a shell a few times and taking the median. The command was as shown.

Memory Use

Differences in memory use between Racket CS and Racket BC are mostly due to bytecode versus machine code, plus the fact that Racket BC can load bytecode more lazily. Various improvements, including changes to the Chez Scheme compiler to reduce code size, have decreased memory use in Racket CS by around 20% for typical applications.

The following plots show memory use, including both code and data, after loading racket/base or racket, but subtracting memory use at the end of a run that loads no libraries (which reduces noise from different ways of counting code in the initial heap). The gray portion of each bar is an estimate of memory occupied by code, which may be in machine-code form, bytecode form, or not yet unmarshaled.

Racket BC heap sizes here are larger compared to previous reports by about 5 MB. That difference reflects a more accurate measurement of the initial Racket BC heap.

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

About the measurements: These results were gathered by running racket with the arguments -l racket/base, -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 Racket BC bar, 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. Code size was estimate using dump-memory-stats counting bytecode, JIT-generated native code, and marshaled code for Racket BC and machine code, relocations, and bytevectors (which are mostly marshaled code) for Racket CS.

Expand and Compile Times

Compile times have improved substantially for Racket CS. The main change was to use an interpreter for compile-time code within the module currently being compiled, because that’s a better trade-off in (meta) compilation time and (meta) run time. Compile-time code that is exported for use by other modules is compiled and optimized normally.

While the Racket CS interpreter and the one in Racket BC are both intended to be safe for space, the Racket CS one stands a much better chance of achieving that goal.

About the measurements: These results were gathered by using time in a shell a few times and taking the median. The command was as shown.

Build Time

The time and memory used to build a Racket distribution using Racket CS is now much closer to the time and memory used by Racket BC. The following plots are all on the same scale, and they show memory use plotted against time for building the Racket distribution from source:

In each plot, there are two lines, although they are often smashed together. The top line is memory use just before a major garbage collection, and the bottom line is memory use just after a major garbage collection.

Racket CS



Racket BC


The Racket CS plot used to be more than twice as wide as the Racket BC plot. About half of the improvement came from fixing a cache that interacted badly with Racket CS’s more frequent minor garbage collections. The rest of the improvement was due to many small improvements.

About the measurements: These plots were generated using the "plt-build-plot" package, which drives a build from source and plots the results.

Run-Time Performance Redux

In some ways, the Racket CS project has validated the Racket BC implementation, because it turns out that Racket BC performs pretty well. With the notable exception of first-class continuations (where Racket BC use a poor strategy), the traditional, JIT-based Racket engine performs close to Chez Scheme.

Then again, development to date has been aimed at making Racket CS match the performance of Racket BC on a code base that was developed and tuned for Racket BC, and that obviously gives Racket BC an advantage. For example, Racket BC makes dormant code relatively cheap, so Racket libraries generate a lot of code. Future Racket libraries will likely shift to take advantage of Racket CS’s cheaper function calls and dramatically cheaper continuations. One day, probably, Racket BC will no longer be a viable alternative to Racket CS for most programs.

To make that prediction more concrete, consider these three ways of counting to 10 million (if N is 10000000):

; self-contained loop
(for/fold ([v #f]) ([i (in-range N)])
; indirect function calls for loop control
(for/fold ([v #f]) ([i N]) ; no `in-range`
; continuations
(let ([g (generator ()
           (for ([i (in-range N)])
             (yield i))
  (for/fold ([v #f]) ([i (in-producer g #f)])

Here are run times normalized to the first one, which is about the same in Racket CS and Racket BC:
















no in-range












While no one will start writing trivial loops the slow way, there’s a big difference between a ×5 and ×25 overhead when choosing how to implement a new abstraction and deciding how much to make static versus dynamic. There’s an even bigger difference between ×335 and ×2672— both irrelevant for a toy loop, but ×335 becomes relevant sooner than ×2672 for more interesting calculations. Overall, when implementation choices start to rely on the R/CS column, the R/BC column will sometimes be unacceptable.

Reflection and Outlook

It took three years to get Racket on Chez Scheme running well enough for production use, and it will take yet more time for Racket CS to fully replace Racket BC. But a certain amount of optimism is necessary to take on a large project like this, and if the timeline gets stretched beyond initial and early projections, then that’s only to be expected.

Racket CS will eventually outpace Racket BC for the reason that originally motivated porting Racket to Chez Scheme: it’s put together in a better way, so it’s easier to modify and improve. Maintainability is difficult to capture with the same clarity as performance benchmarks, but after spending one more year modifying both implementations, I remain as convinced as ever that Racket CS is much better.

This report is the last one for Racket CS. Here are a few things that are on the Racket CS roadmap— but, increasingly, we’ll just call it the Racket roadmap:

  • Support for embedding Racket CS in a larger application. Probably the C API here will start with the Chez Scheme C API, which will make it different from Racket BC’s C API: providing similar functionality, but with simpler rules for cooperating with the memory manager.

  • Improved garbage collection, especially for large heap sizes, including support for incremental collection.

  • Unboxed floating-point arithmetic, especially for local compositions of floating-point operations.

more →

13 Feb 2020

Racket v7.6

posted by John Clements

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

  • DrRacket’s scrolling has been made more responsive.

  • DrRacket’s dark mode support is improved for Mac OS and Unix.

  • Racket CS is ready for production use. We will work to further improve Racket CS before making it the default implementation, but it now consistently passes all of our integration tests and generally performs well. (Compiled code remains significantly larger compared to the default implementation.)

  • The Web Server provides fine-grained control over various aspects of handling client connections (timeouts, buffer sizes, maximum header counts, etc.) via the new “safety limits” construct.

Using this new construct, we have decreased the web server’s default level of trust in client connections and made it detect additional, maliciously constructed requests. Resource-intensive applications may need to adjust the default limits (for example, to accept large file uploads). In trusted settings, they can be disabled completely by starting the web server with #:safety-limits (make-unlimited-safety-limits).

  • The Web Server’s handling of large files is improved, and its latency for long-running request handlers is reduced.

  • The Macro Stepper has a new macro hiding algorithm that tracks term identity through syntax protection (see syntax-arm), making macro hiding work more reliably. Its UI indicates protected and tainted syntax.

  • The Racket documentation includes a “building and contributing” guide.

Contributors: Alex Harsanyi, Alex Knauth, Alex Muscar, Alexis King, Ben Greenman, Bogdan Popa, Brian Wignall, Dan Holtby, David K. Storrs, Dionna Glaze, Dominik Pantůček, Fred Fu, Geoff Shannon, Gustavo Massaccesi, Jack Firth, Jay McCarthy, Jens Axel Søgaard, Jesse Alama, Joel Dueck, John Clements, Jordan Johnson, Julien Delplanque, Leo Uino, Luka Hadži-Đokić, Luke Lau, Matthew Flatt, Matthias Felleisen, Mike Sperber, Paulo Matos, Philip McGrath, Reuben Thomas, Robby Findler, Ross Angle, Ryan Culpepper, Sage Gerard, Sam Tobin-Hochstadt, Shu-Hung You, Sorawee Porncharoenwase, Stephen De Gabrielle, Syntacticlosure, Timo Wilken, Tommy McHugh, Winston Weinert, Zaoqi

more →

19 Nov 2019

Racket v7.5

posted by John Clements

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

  • Almost all of Racket version 7.5 is distributed under a new, less-restrictive license: either the Apache 2.0 license or the MIT license. See https://blog.racket-lang.org/2019/11/completing-racket-s-relicensing-effort.html for more details.

  • Racket CS remains “beta” quality for the v7.5 release, but its compatibility and performance continue to improve. We expect that it will be ready for production use by the next release. We encourage you to check how well the v7.5 CS release works for your programs, and help push the project forward by reporting any problems that you find.

  • The Web Server provides a standard JSON MIME type, including a response/jsexpr form for HTTP responses bearing JSON.

  • GNU MPFR operations run about 3x faster.

  • Typed Racket supports definitions of new struct type properties and type checks uses of existing struct type properties in struct definitions. Previously, these uses were ignored by the type checker, so type errors there may have been hidden.

  • The performance bug in v7.4’s big-bang has been repaired.

  • DrRacket supports Dark Mode for interface elements.

  • Plot can display parametric 3d surfaces.

  • Redex supports modeless judgment forms.

  • MacOS 10.15 (Catalina) includes a new requirement that executables be “notarized”, to give Apple the ability to prevent certain kinds of malware. In this release, all of the disk images (.dmg’s) are notarized, along with the applications that they contain (.app’s). Many users may not notice any difference, but two groups of Catalina users will be affected: those that use the “racket” binary directly, and those that download the ".tgz" bundles. In both cases, the operating system is likely to inform you that the given executable is not trusted, or that the developer can’t be verified. Fortunately, both groups of users are probably also running commands at in a shell, and the solution for both groups is the same: you can disable the quarantine flag using the xattr command, e.g.

    xattr -d com.apple.quarantine /path/to/racket

    TL;DR: Everything is fine. Read this note again if you run into problems.

The following people contributed to this release:

Alex Knauth, Alexander Shopov, Alexis King, Ayman Osman, Ben Greenman, Bert De Ketelaere, Bogdan Popa, Caleb Allen, Chuan Wei Foo, David Florness, Diego A. Mundo, Dominik Pantůček, Fred Fu, Geoffrey Knauth, Gregory Cooper, Gustavo Massaccesi, James Bornholt, Jay McCarthy, Jens Axel Søgaard, Jesse A. Tov, Jesse Alama, John Clements, Jon Zeppieri, Leo Uino, Luke Nelson, Matthew Flatt, Matthias Felleisen, Max New, Mike Sperber, Nick Thompson, Noah W M, Paulo Matos, Philip McGrath, Robby Findler, Ryan Culpepper, Sam Tobin-Hochstadt, Shu-Hung You, Sorawee Porncharoenwase, Stephen Chang, Thomas Dickerson, and William J. Bowman

more →

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