@jesse regexp-quote is often helpful in that kind of case.

How long has the DrRacket arrow popped up a bunch of purple question marks? That’s somewhat recent, yes?

@jhemann it’s done that for a while

Is there a way to document methods in an object without requiring the class to be provided?

Maybe an interface?

Sounds like you are trying to limit information though?

My current preference is to provide both a predicate and an interface, and say that the predicate implies the interface but not vice versa. Here’s an example: https://github.com/rmculpepper/racket-noise/blob/master/noise/scribblings/protocol.scrbl#L166 (the corresponding predicate is documented immediately above).

Thanks!

I’ve used things like private-make-foo or internal-make-foo, especially when some similarly-named public variant also exists.

On QUIC & HTTP/3 in general, I think Racket will want to support it in due course. (IIUC none of the major browsers have HTTP/3 on by default now, though the same applies to HTTP/2.) The multiplexing is supposed to be a major benefit, potentially reducing the need to explicitly bundle CSS and JS to try to shave off round-trips. QUIC also integrates TLS and is probably the shape of things to come in terms of universal encryption.

I’ve played a little with FFI bindings for Quiche, a Rust library by Cloudflare that seems to have good qualities for integrating with Racket’s event loop and port IO. Given the crypto, using an existing implementation via FFI seems probably wise.

But I also run the Racket web server today directly on ports 443 and 80!

I think there’s something like this in raart and slideshow/code, too.

One approach would be to use a shortened name for the argument, like brd, but I don’t like this at all. It’s mildly obfuscating.

The most reasonable approach I can think of is using #:constructor-name in the struct definition, give the constructor a different name, say, new-board.

If I remember correctly, someone here wrote they’re using a capital first letter for struct types, i. e. my struct board would become Board. I’m thinking about this. Downsides I can think of: • The name suggests it’s a struct , which is a disadvantage if you want to treat the function as a black box, i. e. “here’s a function that returns a new board”, and I don’t care if it’s a struct constructor or anything else. • Distinguishing names only by case could be inconvenient when porting code to a Scheme that is case-insensitive. But then you’d probably have more important difficulties than the case sensitivity. :wink: Still, this might be a good naming convention, probably more “natural” than using a new- prefix.

I generally take the Smalltalk-ish approach and say a-board

For the constructor or the function argument?

or like (define (board-combine a-board another-board) ...)

function argument

Only in the case of name conflicts or generally?

I’m not horribly consistent about it :smile:

If I have a hard time figuring out an argument name I use it.

I fear using an a- prefix a lot would look a bit cumbersome.

So a lot of times on name conflicts

good names vs. short names are a hard problem

https://martinfowler.com/bliki/TwoHardThings.html : “There are only two hard things in Computer Science: cache invalidation and naming things.” :slightly_smiling_face:

I totally agree. :smile:

yes

In Smalltalk (and now with more support for LSP in other IDEs) long names aren’t so bad because you just tab complete them, and it makes the code more readable later.

> good names vs. short names are a hard problem If in doubt, I prefer longer, but more informative names. I’ve done this for a long time, regardless of language.

Something you can do is go for two-word type names instead of one-word type names, for instance chess-board instead of just board

That way the single-word form works as an abbreviation you can use for variables

(the namespacing benefit of OOP method call syntax is vastly underrated)

But you could potentially package it as a Racket package for x86_64-linux-natipkg and add it as a platform-specific dependency.

Would that get my docs on the doc server?

Yes: I basically mean the approach at https://pkg-build.racket-lang.org/about.html#foreign, but for an executable, rather than a library.

Hm. Part of the problem is that the docs render using pygmentize , so I don’t see how this solves that problem.

I know little about pygmentize, but I’ve packaged xmllint for Windows: https://github.com/LiberalArtist/xmllint-win32-x86_64 If you arrange to run the pygmentize you’ve packaged on x86_64-linux-natipkg while building the docs, then you’re set.

Okay. I’ll take a look, thanks!

Maybe the more useful place to look is where I use xmllint: https://github.com/DigitalRicoeur/ricoeur-tei-utils/blob/master/tei/kernel/xmllint.rkt (I don’t know that any of this is terribly elegant, but it works.)

There’s some discussion at https://issues.guix.gnu.org/47614, https://issues.guix.gnu.org/47180, and https://issues.guix.gnu.org/47064 about problems with GNU Guix attempting to re-write string constants in .zo files. I think the solution is that Guix should not try to do that, but any insight from someone who actually knows the details about strings in CS .zo files would certainly be welcome.

I agree that not doing this seems best, although it’s possible that it could be made to work

But what string constants are the issue?

So, for example, on Guix, libgtk-3.so.0 would be at a path like /gnu/store/n2cnp2fivxq10kxqalcv2q41wzsyj9yd-gtk+-3.24.24/lib/libgtk-3.so.0 . Currently, Guix patches source files like mred/private/wx/gtk/gtk3.rkt to use the absolute paths to foreign libraries. However, GTK and its dependencies sometimes have security updates. Any change in GTK’s inputs would change the hash embedded in its path, but it can be desirable to distribute security updates faster than the Guix build farm would be able to rebuild everything properly. In such cases, Guix can use a mechanism called “grafts” which rewrites the build products of the desired packages (skipping intermediates) to refer to the patched dependency. But this obviously is very brittle! IIUC there’s also a known issue with Steel Bank Common Lisp, which stores compiled strings in UTF–32 or something.

There’s a binary dump at https://issues.guix.gnu.org/47614, but it seems the .zo files can (under some set of circumstances) split such strings into chunks. Potential bad outcomes from botched “grafting” seem to include running the unpatched library, not finding the library at all (because Guix might have “garbage collected” the unpatched one), or Racket crashing with an internal error from $bytevector-uncompress.

Ok that makes sense. I continue to think the practice of requiring absolute paths is weird, but given that I understand the problem. Unfortunately I don’t think there’s a general mechanism for patching zo files, at least not one that would avoid writing racket code.

Yes. Instead, I’ve proposed putting the paths in config.rktd’s lib-search-dirs, which seems to avoid the problems.