@deactivateduser60718 @mflatt would know for sure but that looks like a bug to me

I agree that it looks like a bug.

@mflatt @samth Thank you. I’ll have an issue up for you in the racket repo once I get reproduction instructions ready.

Is there a procedure to force the Racket Web Server to read the SSL certificate again? Every three months I renew my certificate as ‘Let’s Encrypt’ forces me to, but then I have to restart the server to read the SSL certificate again — as I don’t know how else to do it.

This is achievable if you create your own SSL TCP unit, but it’s a bunch of error-prone work. I’d recommend just running a reverse proxy like nginx in front of your Racket app to handle TLS termination since certbot integrates with it fairly well.

Cool. I’ll look into nginx. I never used it. Thanks!

@mflatt Second topic: I just regenerated Vulkan bindings to match updates to their spec. Racket crashes on the result due to what I assume is a bad declaration/alignment. The continuation marks do not clarify which type went wrong, and there’s about 2000 declarations to sift through. I doubt this is a bug in Racket, but any advice on what I can do to make this error more informative?

Relevant diff: https://github.com/zyrolasting/racket-vulkan/commit/26fbbf72c6ec85d824097aca684254f7c547cc28

[sage@localhost vulkan]$ racket unsafe.rkt modulo: division by zero context...: condition->exn do-raise dynamic-wind loop make-cstruct-type /home/sage/racket/collects/ffi/unsafe.rkt:32:27: _list-struct interpret [repeats 1 more time] proc call-in-empty-metacontinuation-frame body of "/home/sage/Code/vulkan/unsafe.rkt"

A low tech solution is to prepend each line in unsafe.rkt with (displayln i) where i is the line number.

Or insert, say, (/ 1 0) at line 1000 to see whether the error occurs before or after line 1000 (then rinse and repeat to narrow it down).

Got it.

Redefine modulo maybe?

(oh unless it’s coming from somewhere else, oops)

Life was easy on Windows. Upgrading libsqlite3 on Ubuntu, though, isn’t as easy. I tried unsuccessfully to compile https://www.sqlite.org/src/tarball/sqlite.tar.gz and I get errors. Trying other ways, I tried a precompiled library, but it was compiled against a newer libc, so I can’t install it (and if I could, it wouldn’t run!), so I might have to install a whole new system just to get a newer libsqlite3, which is crazy. The root-problem is really my inability to compile the source code. If I could build the library, it’d probably be a smooth installation.

For the record, the compilation goes like this: https://pastebin.com/raw/7NMrqMLB

There is no header missing, so I see no reason for unknown type name 'sqlite_int64'. Won’t dig into this.

Of course, I can always just write

(define (delete-by-id id) (query-exec db-conn "delete from offerings where item_id = $1" id))

and move on. :-D

Are .plt files made with raco pack Racket version dependent?

@samth and others: I merged to master and it has flowed through to MELPA https://melpa.org/#/racket-mode so you may install/upgrade the usual way.

Also I just refreshed the online docs: https://www.racket-mode.com/

Probably _list-struct should complain when it gets an empty list of fields, and maybe that would have helped. (The argument checking of exports from ffi/unsafe has never been as good as it should be.)

I figured there would have been an empty declaration, but did not see one via Ctrl+F. Is that the only way this error could occur?

Hi all. I have downloaded the racket source code to see what it is written in and I am pleased to see that I was able to compile it with gcc! Does racket really only need a C compiler or is it hiding some bytecode from me? e.g. I was recently disappointed to learn that polyml (a standard ML impl) ships with a bunch of x86 machine code.

and does the same go for Typed Racket, can I basically go from C compiler to a working Typed Racket compiler? :heart_eyes:

Sweet! Thanks again for all your work on this!

From https://github.com/racket/racket/blob/master/build.md

> Minimal Racket does not require additional native libraries to run, but under Windows, encoding-conversion, extflonum, and SSL functionality is hobbled until native libraries from the "racket-win32-i386" or "racket-win32-x86_64" package are installed.

If I understand correctly it is possible to bootstrap Racket directly from source. So in that sense there is no hidden bytecode.

Ah, found it: there was a (_list-struct _void).

yup, I read those docs, and I even compiled it locally, but I’ve been burnt by other compilers that claim to be “from C” but actually end up using some mystery meat binaries under the hood.

The GUI depends on a few external libraries though. Cairo, Pango and others.

is typed racket written in racket, or is it a separate compiler?

Typed Racket is implemented in Racket.

oh, I am not going to be using anything except GNU Emacs… you can pry it from my cold dead hands :grimacing:

In that case, don’t forget to use racket-mode

well this is fantastic. I am suddenly very interested in Racket and wishing I had some free time.

the Typed Racket docs have an FAQ about how match sometimes doesn’t work, but it doesn’t have a section about when it does work… can I assume that match will give me exhaustivity checknig over union types?

As far as I know (but I am no expert in Typed Racket) the answer is no - at least when it comes to the standard matcher.

However I think there is a chance that someone has implemented such a datatype.

The conservative GC version of Racket is built from the C source, then that version of Racket (Racket CGC) is used to do some source-to-source translation of the C code to build the precise GC version of Racket (Racket 3m), but there are no binary images involved in the process.

(also, thank you for all your work on Ensime; I used it a lot years ago)

:blush:

thus begins the rabbit hole to implement exhaustivity checking :laughing:

Maybe I am wrong: https://gist.github.com/gbluma/6752652

I’d considered the possibility of writing a macro for scheme or something that would generate union reprs and then patterm matcher macros to use for them, but that all started to sound a bit too crazy for me.

nice!

The problem is what “union type” refers to. In standard untyped Racket, union types are often implicit.

I am not sure, what Typed Racket offers though. But hang around the Typed Racket experts are here often.

I don’t even need this fancy guard based pattern matching, I was just looking for something that makes sure I considered all the “data constructors” (or whatever the equivalent is)

but I can probably guess that all the data constructors are really just guards in disguise, if it’s doing what I think it’s doing.

I also noticed on the main Racket Lang landing page that it is being promoted as a compiler designer’s language… has anybody considered writing a Haskell interpreter or compiler in (Typed) Racket?

that would be a real dream project for me

Alexis has written Hackett.

https://lexi-lambda.github.io/hackett/

heh, yeah I seen that … it’s cool. But that’s a totally new language taking inspiration from haskell and racket. I was thinking more about a Haskell2010 compliant compiler.

(there’s also Liskell which is ghc with the lexer/parser rewritten)

@sam.halliday Typed Racket works by expanding a Racket program and typechecking the expansion, so match is just the ordinary Racket match. Racket’s match doesn’t do exhaustivity checking, so TR’s necessarily doesn’t, either. You could certainly write your own match that works differently, but that isn’t something TR has done, historically.

ah, cool, well that’s still very interesting.

I think writing a standards-conforming Haskell 2010 implementation in Racket would mostly be a pointless exercise, aside from as a learning opportunity (though of course it would be good in that regard!). You’d end up with something strictly less useful than GHC Haskell! It would be an interesting project to try and add macros to Haskell syntax, of course, but that would be a serious undertaking.

Wtihout funding such a project would of course never be finished, but I think there is merit in having an alternative to ghc. Even if it is only to harden the language standards and provide a mechanism for bootstrapping ghc itself.

It concerns me that so many modern languages require previous versions of the compiler to build. Some languages are impossible to build without relying on a mysterious binary or unreleased proprietary compiler. e.g. very early versions of Scala require access to an Oracle-owned experimental language.

You are thinking of the Ken Thompson talk/paper?

well, yes, and there was a proof of concept of that attack, but also portability.

and to avoid vendor lockin

taking haskell (ghc) as the example, we are all at the mercy of the development of ghc. It will be very difficult to go back to an older version of ghc to fork it, and eventually older versions of the compiler will be lost to us forever.

You might enjoy this diagram of how we start from C to compile Racket to compile a better Racket to compile a Racket simulation of Chez Scheme to compile Chez Scheme to compile Racket CS.

No T’s :wink:

Thanks all, that’s been incredibly useful. I will now be able to dream about writing a Haskell compiler in Typed Racket, after I write an exhaustivity checker. Now all I need is some free time, which should be in about 2 decades when my kids are ready to leave the nest. :wave:

but I’ll sleep well tonight knowing that I have a project waiting for me

Note that there is one piece of pre-compiled code that you basically have to use, which is the fully expanded version of the expander. That’s checked in to the repository.

Technically it would be possible to go back through the racket7 repository to rebuild it repeatedly from the C version of the expander but no one has attempted that and I would recommend not trying.

However, the good news is that it’s not at all like machine code, it can be pretty readable.

And modifiable, since it’s just an S-expression with a lot of extra quotes around it. I have temporarily fixed bugs directly in “startup.inc” on a couple of occasions when it would have been a pain to roll back to bootstrap.

It would be “interesting” to try to make the expander work again in 6.9