Do you accept PR’s for https://racket-stories.com ? @soegaard2

@spdegabrielle Yes.

Terminal tip of the day: open . opens a Finder window displaying the current folder.

@soegaard2 have you met the git switch --no-edit ??

no?

git commit -a --amend --no-edit

could probably become git-whoops-forgot-that-one

Great tip - could have used that more than once…

I figured I’d try to take a stab at this and I’ve built everything locally, but I can’t get any changes I make to the expander to have an effect. My process right now is:

1. edit a file within the expander
2. run make
3. run ./racket/bin/racket my-test-case.rkt

Is there anything else I need to do when I modify the expander? I’ve gone as far as throwing an (error 'wat) at the top of require+provide.rkt but even that doesn’t seem to have an effect.

you need to run make inside the expander directory

Ah! Thank you :smile:

the expander is compiled into the binary from a c source file that’s generated by that make step

and it isn’t regenerated by default with top-level make

you can also look at the README in the expander dir for ways to run it directly

OK, that makes sense. I completely missed that there was a README in there. Thanks again!

Does something like this look OK to you?

tmp/c.rkt:4:9: module: identifier already required
  provided by: "a.rkt"
  at: x
  in: "b.rkt"
  location...:
   tmp/c.rkt:4:9

c requires a and b, which both provide x

how about “also provided by:”

perfect

Didn’t know that. I’ve been using git commit -a --amend --reuse-message=HEAD.

if I have a module with (require (file "stuff.rkt")) that I dynamic-require in, is there a way to control what path that require is relative to?

the docs say the path is: “A path relative to the containing source (as determined by current-load-relative-directory or current-directory). “, but the path I’m getting is actually the current directory of the module I’m dynamic-requireing in.

@dan.ml.901 current-load-relative-directory is maybe what you want

it doesn’t seem to be used…

note that (require (file "foo.rkt")) and (require "foo.rkt") are different

the latter should be relative to the file

true, i’m trying both as I go

they seem to (mis)-behave in similar ways

the former is different and may be best used for absolute paths

is the module in a file?

dynamic-require sets current-load-relative-directory, so it doesn’t help to parameterize dynamic-require. If you want to control that level, you have to read-syntax and eval the module declaration.

@dan.ml.901 FWIW, in my projects I have a hard ban on using file paths with require. Instead I always use collection-based paths like (require foo). If you’re comfortable with racket’s package manager and you’re not doing something odd, this approach might save you some headaches.

i’m taking advantage of require to load non-.rkt files so the collection based approach runs into file extension issues

i’m hoping to use precompilation soon…

is there any possibility I can rework/reimplement dynamic-require?

ah dynamic-require uses eval

@dan.ml.901 You can load non-rkt files in collections. (require foo) is short for (require (lib "foo.rkt")). Using the longhand form you can use any extension. Won’t look as pretty, but it works.

@dan.ml.901 Would a define-runtime-path help?

@soegaard2 that looks promising…

it seems like (require (lib "foo.myext")) will look for "foo.myext" in the mzlib collection only

Oops, my bad. It’s slightly more complicated. (require foo/bar/baz) is short for (require (lib "foo/bar/baz.rkt")), but if there’s only one part to the path like (require foo), it looks for the main.rkt file so that becomes (require (lib "foo/main.rkt")). So you probably want (require (lib "foo/main.myext")).

ah that seems to get me further, thanks!