Syntax Parse Bee 2021 Write a macro with Racket this summer! Win stickers!

It’s like a Quilting Bee, but for syntax parse macros!

In this case the ‘quilt’ is a patchwork of syntax-parse macros.

https://github.com/syntax-objects/Summer2021/blob/master/ANNOUNCEMENT.md\|https://github.com/syntax-objects/Summer2021/blob/master/ANNOUNCEMENT.md

What is the policy (if there is one) about typed/racket in the standard lib? For example, if one refactors a lib module into a github PR, is there a preference for #lang racket? What about main-but-not-std libs such as data?

AFAIK:

• racket prefers vanilla Racket. I don’t even know if it’s possible to use Typed Racket there, since it’s likely going to cause a cyclic dependency.

• Number crunching libraries usually prefer Typed Racket. E.g., math and plot

• There are other uses of Typed Racket, but they are very rare. E.g., in scribble, there’s https://github.com/racket/scribble/blob/master/scribble-lib/scribble/blueboxes.rkt

I’d prefer #lang racket/base. Some people use racket/base to reduce startup time. I use it often. A “Hello world” from raco exe with #lang racket/base on my computer takes about 100 ms and with #lang racket it takes 300 ms. (For the record, with #lang typed/racket the time becomes about 650 ms.)

My understanding is that as soon as you directly or indirectly require one module that uses #lang racket you lose all the startup time advantages of #lang racket/base. Is this correct?

Yes, although there’s a corresponding #lang typed/racket/base

By the way, using #lang racket/base with (require racket/match) leads to a run time of around 230 ms. That’s why I avoid racket/match for short-running programs. :wink:

> Yes, although there’s a corresponding  #lang typed/racket/base A raco exe-compiled “Hello world” with #lang typed/racket/base takes 550 ms here.

But of course, for numeric-heavy stuff, Typed Racket will help a lot. :slightly_smiling_face:

Libraries should never use #lang racket; they should use #lang racket/base instead. (For the reasons listed by @sschwarzer). Ask before adding a dependency on Typed Racket to a package that doesn’t already have one. (Or before spending significant effort to prepare a PR that does so.) The answer is likely to be “no”, but maybe not, and it’s probably worth having the conversation.

Currently, I have a project that if I build it with raco exe --gui .\main.rkt (on Windows 10), it works perfectly. However, if I build it from DrRacket it fails to run afterwards; no error is shown, the app launches the process and then dies immediately.

In DrRacket, I have the “gracket” option picked (which I assume is the same as --gui), and I also have the “Embed DLLs” option checked. I’m unsure what the difference(s) could be. Anyone have any ideas?

Does using raco exe --embed-dlls --gui main.rkt produce a working executable?

No. And building that way (and running from the terminal) produced a console window with an error:

ssl-connect: context creation failed (error:00000000:lib(0):func(0):reason(0))

Is the embedded openssl.dll different from the one installed on my machine that it’s finding in the PATH when not embedded?

(e.g. perhaps it’s using one from the racket distro when embedding that’s problematic)?

In v8.1 and earlier, the OpenSSL library doesn’t work with --embedl-dlls . This has been fixed for v8.2 and in snapshots.

ok. looking forward to 8.2 then :wink:

See also https://github.com/racket/racket/issues/3655