Jan Dvořák | 28 Jan 13:49 2015

feature request: thread-safe memoize-evt


I would like to ask for another extension of the Racket's event handling
system. A `memoize-evt` constructor with following semantics:

Given a base event E_b, memoize-evt will produce a memoizing event E_m.
Synchronizing on E_m from any number of threads will block until a
single value is produced by E_b. This value is then stored inside the
E_m. From that moment on, E_m will always be immediately ready for
synchronization and produce the stored value in all waiting threads.

The single-threaded implementation is a trivial guard-evt + replace-evt
+ (wrap-evt always-evt) combo, but for thread-safety a temporary thread
would be needed to wait for the base event and the solution would have
different semantics then rest of the event system.

A lower-level approach would also be possible; create something along
the lines of a dynamic-wind-evt that would, with some cleverness, allow
for generic thread-safe events via locking. Or create a locked-wrap-evt
constructor that will not be ready until it's handler finishes.

Hoping that I am not being too bothersome,
from Prague with thanks,
Jan Dvorak

  Racket Developers list:

(Continue reading)

Ryan Culpepper | 23 Jan 21:31 2015

Release process for split repos

I’ve added a draft of a new release process that takes the repository split into account. The main
difference is that there is no longer a single release branch under central management; instead, there is
a release branch for each repository, and management responsibilities for package release branches is distributed.

The wiki page is here:


Please review, ask questions, and point out ambiguities and potential problems.


  Racket Developers list:

Xiangqi Li | 23 Jan 17:12 2015

A Debugging Tool for Better Printf

Hi Racketeers,

Recently I've been working on a debugging tool, Medic, to improve the debugging experience with printf. My project is available on Github:


To get started, you can install the medic package and build the documentation for a user manual. The package also incorporates executable examples used in the documentation in the demos directory. I'd like to hear suggestions and complaints, and your feedback about Medic is very appreciated. Thanks,

  Xiangqi Li
  Racket Developers list:
Alexis King | 22 Jan 21:57 2015

In Typed Racket, struct declarations do not work in an internal definition context

Simple enough. This works:

#lang racket

(define (make-me-a-struct)
  (struct foo ())

(make-me-a-struct) ; => #<foo>

This does not:

#lang typed/racket

(define (make-me-a-struct)
  (struct foo ())
  (foo)) ; error: cannot apply a function with unknown arity


This problem makes sense. Type declarations seem to be a module-wide construct, so a type that should be scoped to a single function doesn’t work. I’m running into this issue when trying to create an executable struct using define-struct/exec from within a macro, which doesn’t work due to this particular problem.

I can work around this in a variety of ways—I can extract this into an untyped module and use require/typed, I can use vectors to “fake” structs and provide an appropriate interface, etc. Still, I wonder if there are any plans to resolve this type of problem? Since it seems to be an issue with how TR handles types at its core, I’m not even sure how feasible it would be.
  Racket Developers list:
Jens Axel Søgaard | 22 Jan 11:24 2015

Literal constants

This program returns #f - I was expecting to see #t.

    #lang racket
    (define a '(1 2 3))
    (define b '(1 2 3))
    (eq? a b)

Why not guarantee uniqueness of  literals occurring in the same module?

/Jens Axel
  Racket Developers list:

Byron Davies | 21 Jan 19:03 2015

Full transparency

Would it be easy to create a compiler flag that would make every struct and object transparent?  This would then make it easy to create a Lisp Machine-style Inspector that would be able to roam through every data structure during debugging.


  Racket Developers list:
Tony Garnock-Jones | 21 Jan 17:22 2015

(reposted from users) Noisy compiler at PLTSTDERR=info

[Reposted from -users, since it seems likely I erred in my initial
selection of that list]

Hi all,

Over the past few months, more and more subsystems have started logging
at info level as part of regular compilation.

I prefer having PLTSTDERR=info in order to catch log-info that happens
at runtime, and find the compile-time log output quite distracting.

My current workaround is to set

PLTSTDERR="info warning <at> cm warning <at> compiler/cm warning <at> module-prefetch
warning <at> setup/parallel-build warning <at> cm-accomplice
warning <at> online-check-syntax"

but this is quite verbose, and as subsystem log messages come and go
I'll need to keep updating it.

Could one of the following ideas be worth exploring?

 1. Have a superlogger for these (and other?) compile-time-ish loggers,
    so that I could write "info warning <at> compilation", excluding the
    noise in one fell swoop

 2. Have a phase number associated with logging, so I could say
    "info <at> 0 warning <at> 1", or similar

-- Tony
  Racket Developers list:

Christian Eitner | 20 Jan 10:25 2015

Compiling a Debuggable Windows Build

Hello everyone,

I'm trying to analyze bug 14927, which simply states that I cannot
save any kind of definitions file from DrRacket on Win7 64. The
message is "Racket GUI application has stopped working", i.e., the
windows crash dialog.

I'm pretty sure the problem is related to my machine only, since on a
colleague's PC everything works fine.

So I need a Windows build which I can debug. Is there something on the
build servers which I could use?

I could build locally, having both a Visual Studio (10, 12, 13) and a
Cygwin 64 environment, or even cross-compile on Ubuntu if that was

BTW, how are the provided Windows builds being generated?

Any hints would be welcome.

Thanks for your consideration,

  Racket Developers list:

Alexis King | 15 Jan 08:44 2015

Implementing contracts for async channels

Currently, async channels do not have contracts to check their contents. This is a problem for Typed Racket, and it prevents typed code from interacting with code that produces async channels.

I started looking into how to add contracts to the language, and it seems to use the chaperones/impersonator system, as I suspected. However, async channels obviously cannot be impersonated, so I needed to implement that as well.

I modified the async-channel struct to use generics to allow it to be impersonated or chaperoned, which I have exposed by implementing chaperone-async-channel. I then tried implementing async-channel/c. The internals of the contract system are a little beyond me, but I got a working solution by following the example of the box contracts.

First of all, is this a correct approach? Have I done anything wrong, or should I have done anything differently? I didn’t find much documentation on the internals of either of these systems, so I mostly went about things as I found them.

Second, obviously, not everything is implemented here. Among the additional necessary changes are:

  • I need to implement support for impersonators and impersonator contracts (right now I’ve only bothered to do chaperones).
  • I need to implement async-channel/c-first-order and async-channel/c-stronger. I can probably figure out the latter, but I’m not even sure what the former is supposed to do.
  • I need to implement a wrap-async-channel/c macro for the export. I’m not sure how this works, either. From looking at wrap-box/c, it seems to add some syntax properties, but I’m not sure what they do or how they work.
  • Somehow, the blame information has to be correct. Is that what the wrap function does? Or do the async-channel functions need to be updated to assign blame?

I’d really like to get this working, and I think I’m close, but I’m a little inexperienced. I’d appreciate any help, even if it’s just pointing me in the right direction.

  Racket Developers list:
Thomas Lynch | 15 Jan 06:12 2015

question, issue(?) with the scope of identifiers passed into define-syntax-rule

I have a simple syntax rule:

  Welcome to Racket v5.2.1.
  racket <at> > (define-syntax-rule (with-tables stem body ...)
          [table-publication (string-append stem "_publication")]
          [table-author (string-append stem "_author")]
          [table-bridge-publication-author (string-append stem "_bridge_publication_author")]
          [table-unique-counters (string-append stem "_unique_counters")]
      body ...

Which works fine when I don't reference the environment defined by the let:

  racket <at> >
  racket <at> > (with-tables "x" "hello")

However when I pass it an identifier corresponding to one of the variables defined in the let:

  racket <at> > (with-tables "x" table-author)
  reference to undefined identifier: table-author
  stdin::1167: table-author

The identifier passed in doesn't seem to be part of the local let context, but carried in a different context, or perhaps it was evaluated as an operand.  I didn't expect either of those.  Can someone point me at a description of the expected behavior, or give me a tip here on what is happening and why.

... in Wolfram language there is a 'Hold' operator for situations like this.  Apparently inside the macro we have to do some evaluation to handle the work of the macro,  is that why the operand is evaluated?

Thanks in advance for explaining the evaluation/context model here.

  Racket Developers list:
David Van Horn | 15 Jan 01:11 2015

Announcing Soft Contract Verification tool


Over the last year, we've been working on a tool for automatically
verifying that programs live up to their contracts. We're happy to
announce that it's now available for people to try out here:


You type in some modules in the editor, and click either Run or
Verify. The Verify button uses our tool to determine if the modules
always live up to their contract, and if they don't, it automatically
generates a counterexample, showing how to break the module. There are
a number of examples that you can play with, accessed via a menu on
the site.

Right now, the tool supports a fixed subset of Racket, but we're
working on making it handle much more by analyzing fully-expanded

There's explanations on the site to go along with each example
program, and there's an "About" page with more info, and links to our
papers about the work, at http://scv.umiacs.umd.edu/about

We plan to release a command-line tool and a DrRacket plugin in the
future, once we can handle more of Racket.

If you have questions, comments, bugs, or any other feedback, let us
know, or just file bug reports on the GitHub source code.

Phil, David, Sam
  Racket Developers list: