
I’m trying to use the racket web server to serve up custom javascript modules.
I use this to create the response:
(define (response/mjs str) (response/full 200 #"" (current-seconds) #"text/javascript" cors-headers (list (string->bytes/utf–8 str))))
This xexpr fragment generates the html that requests the javascript:
(script ((type “module”) (src “initialize.mjs”)))
This is the relevant part of the dispatcher that sends the response:
(dispatch-rules+applies [(“initialize.mjs”) (lambda (req) (response/mjs initialize-script))])
where initialize-script is a string representing a javascript module.
Sadly, the browser complains that the server is supplying the data with mime type text/html when the type="module" declaration tells the browser to expect mime type text/javascript.
Why doesn’t the #"text/javascript" mime-type in response/mjs result in the right mime type going to the browser?

This minimal example works for me:
#lang web-server/insta
(define (start req)
(response/full
200 #""
(current-seconds) #"text/javascript"
empty
(list #"foo")))

The header does say it’s text/javascript

Do you have the same result?

@jbclements have you noticed some ci build fails for the release
branch ?

@byron
(script ((type "module") (src "initialize.mjs")))
likely should be
(script ((type "module") (src "/initialize.mjs")))
If that doesn’t fix the problem, you should take a look at your browser’s dev tools’ network inspector to see what is being returned by the server.

I’m having an exploration into ARM assembler at the moment and fancy writing a basic scheme/lisp. I have some ideas about memory management for basic primitive types but it would be useful to see how racket does it. Can anyone point me at the appropriate area of the code, or to any docs that explain the memory model?

I’m not sure but I think the ‘inside racket’ seminar series might have had something on that…brb



@spdegabrielle Cheers, I was just thinking most languages these days will at least be written in C (structs etc.) but it might give me a few ideas.

there is a core written in C/C++ But my understanding is there was a re-write a few years ago that re-implemented a bunch of C in Racket.

I suppose the goal is often to write a language in itself, but the core always has to be in something relatively low level, I might be going too low level with assembler, but I just wanted to give it a try.

FWIW There is a crossplatform assembler to 6502 that leverages Racket for assembly https://docs.racket-lang.org/asi64/index.html#%28part._racket._integration%29\|https://docs.racket-lang.org/asi64/index.html#%28part._racket._integration%29

Cool

@mark.warren Andy Keep gave a keynote talk at the Scheme workshop last year about Chez Scheme and its bit-level representations and the optimizations it enables. Racket CS inherits them, and the old implementation of Racket uses similar tricks, but less extensively. You can find the video of the talk online.

@ryanc That should be interesting, I’ll take a look.


Thanks @spdegabrielle

this is awesome work :smile:

All credit goes to the authors - I just learnt how to use the ‘built packages’


I am in shock - in my mind Andy Keep looked like: https://youtu.be/Os7FE3J-U5Q?t=53

Are these the same Andy Keep

?

Oh - the video I posted is from 6 years ago it seems… still… wow!

I need someone to confirm if I’m now understanding how to split a single-collection package into several multi-collection packages. Here’s my next attempt for polyglot
: https://github.com/zyrolasting/polyglot/tree/package-reorg
To recap: The way I’ve normally worked is by making a single-collection package with raco pkg new
, then using raco pkg install --link
to work on the package locally. I would update my docs by running raco setup polyglot
.
It seems the equivalent here is to run raco pkg install ./polyglot-lib ./polyglot-doc ./polyglot-test ./polyglot
, then update with raco pkg update polyglot-doc
or something.
My understanding is that the metapackage comes last for local installation, because if I open with raco pkg install ./polyglot
then the command is just going to run off to the catalog.
Two questions:
- Is the workflow I described above correct and practical?
- Will my users still be able to run
raco pkg install polyglot
to get everything as I have it set up in the link?
EDIT: formatting

@deactivateduser60718 Do you have an implies
list in the info.rkt
for the polyglot
package?

Ah yes you do, nevermind

Looks like we hit 1000 Slack users sometime this week (today?)! :tada:

@me1419 has joined the channel

This looks good to me. I’d maybe remove polyglot-test from implies so that code doesn’t get shipped over to people

1001*

I’ve written a family of for/list
-like forms that accumulate in the opposite order. Does anyone have an opinion about what to name them? I’d initially thought for/reverse-list
, but then I thought that was confusing, because it’s for/list
that does a final reverse
: these are non-reversed. I’m currently thinking for/list/left
, by analogy to foldl
(whereas for/list
is analagous to foldr
). But does that seem too obscure?

is racket cs significantly faster since it compiles straight to native :0?

Going for brevity: for/cons
?

As of the last report (from a year ago), most things are faster, some slower:
https://blog.racket-lang.org/2019/01/racket-on-chez-status.html

I think a con of for/cons
is that it breaks the convention of naming the for
-like form after the result type.

There’s a more recent report, from ICFP 2019: https://www.cs.utah.edu/plt/publications/icfp19-fddkmstz.pdf

It says: “production Racket programs tend to perform somewhere between slightly faster and 50% slower on Racket CS” (p. 12).

Beyond the main four info.rkt files, I notice a few more in the codebase that I didn’t expect (polyglot-doc/polyglot/info.rkt, polyglot-lib/polyglot/info.rkt, and the empty polyglot-test/tests/info.rkt). I’ve never seen some of the info.rkt features you’re using, so maybe you’re getting some use out of those, but I mention it in case it’s unintentional.
Anyhow, the main four info.rkt files look like they’re set up nicely.

I think having “reverse” somewhere in the name is likely to be the clearest option overall.
A list-combining operation that takes (list 1 2 3)
and (list 4 5 6)
and returns (list 3 2 1 4 5 6)
may be one reverse
short of being append
, but I don’t think that means append
is the more reversed of the two operations.
I wonder if the analogy to foldl
/foldr
really makes sense. Regardless, it does at least make enough sense that I’d find it comfortable to work with; I think simply the fact that it refers to a direction can be an enough to remind me that it does something in a different direction than I might otherwise expect.

@rokitna The one in the doc package was me shamelessly copying the format from https://github.com/stchang/graph/blob/master/graph-doc/graph/info.rkt. I figured that since the info.rkt in polyglot-doc
specified 'multi
, there was some meaningful difference for info.rkt
files for collection directories.

I’m guessing what I’m seeing was an artifact of setup/infotab
?

https://github.com/zyrolasting/polyglot/tree/package-reorg Updated according to feedback

I’m not familiar with what that graph library’s doing with that info.rkt either. It’s probably something; I just don’t know what it is. XD

Unless I did something odd, it does look like it makes a difference. If I move scribblings
from the extra info.rkt
up to polyglot-doc/info.rkt
and add polyglot/
to the beginning of each path to accommodate, my docs no longer build. I tried removing the polyglot/
prefix again just to see if that mattered, but the docs still did not build. It was only with the extra info.rkt
file did I actually see my docs build and make it into the index.

@rokitna I started thinking about it in terms of left vs. right folds in part because of for/foldr
[1]. A naïve implementation of for/list
would use for/foldr
for a right fold: #lang racket
(define-syntax-rule (for/list clauses body ...)
(for/foldr ([acc null])
clauses
(cons (let () body ...) acc)))
(But for/fold
doesn’t actually work this way because of a limitation [2] in the traditional Racket VM’s implementation of continuations. There’s some more discussion at [3].)
[1] https://docs.racket-lang.org/reference/for.html#(form._((lib._racket%2Fprivate%2Fbase..rkt)._for%2Ffoldr)) [2] https://github.com/racket/racket/issues/1721 [3] https://github.com/racket/racket/pull/2656

for/reversed-list
, since the pattern I see is for/<noun phrase>

@philip.mcgrath also you might be interested in for/reducer
and make-reducer-based-for-comprehensions
https://docs.racket-lang.org/rebellion/Reducers.html?q=for%2Freducer#%28form._%28%28lib._rebellion%2Fstreaming%2Freducer..rkt%29._for%2Freducer%29%29\|https://docs.racket-lang.org/rebellion/Reducers.html?q=for%2Freducer#%28form._%28%28lib._rebellion%2Fstreaming%2Freducer..rkt%29._for%2Freducer%29%29

Someone on Reddit noticed that the Utah mirror for the 7.6 download isn’t working https://www.reddit.com/r/Racket/comments/f3me65/racket_version_76_is_now_available/fhjsdm4?utm_medium=android_app&utm_source=share\|https://www.reddit.com/r/Racket/comments/f3me65/racket_version_76_is_now_available/fhjsdm4?utm_medium=android_app&utm_source=share

Both of these projects work locally, but fail in the CI builds after trying to split them into lib
, test
and doc
packages.
• https://pkg-build.racket-lang.org/server/built/fail/polyglot.txt • https://pkg-build.racket-lang.org/server/built/fail/unlike-assets.txt I took a guess at what I should do off master
in the related source. Are the info.rkt
files correct?
• https://github.com/zyrolasting/polyglot • https://github.com/zyrolasting/unlike-assets

I asked about this in a thread earlier, but it doesn’t seem like I can declare victory yet.

It looks like you haven’t updated the https://pkgs.racket-lang.org/ catalog to add the -lib
, -doc
, and -test
packages and change the source for the umbrella package to point to the right subdirectory, rather than the root of the git repository. The package build service is using the old source for the umbrella packages, so it’s trying to install the repository root as a package.