Hello. I am getting the following error while trying to install racket packages echo "a" \| raco pkg install http-easy yaml rfc6455 web-server request relation open-input-file: cannot open module file module path: /home/root/user/.local/share/racket/8.1/pkgs/reprovide-lang/reprovide/test/example-directory/a.rkt path: /home/root/user/.local/share/racket/8.1/pkgs/reprovide-lang/reprovide/test/example-directory/a.rkt system error: no such file or directory; rkt_err=3 compilation context...: /root/.local/share/racket/8.1/pkgs/reprovide-lang/reprovide/test/other-subdir/indirect-glob-in.rkt context...: /usr/share/racket/collects/compiler/private/cm-minimal.rkt:610:0: compile-zo* /usr/share/racket/collects/compiler/private/cm-minimal.rkt:409:15 /usr/share/racket/collects/compiler/private/cm-minimal.rkt:398:12: build /usr/share/racket/collects/compiler/private/cm-minimal.rkt:374:0: maybe-compile-zo /usr/share/racket/collects/compiler/private/cm-minimal.rkt:208:0: compile-root /usr/share/racket/collects/compiler/private/cm-minimal.rkt:104:4 /usr/share/racket/collects/setup/parallel-build.rkt:332:9 /usr/share/racket/collects/setup/parallel-do.rkt:455:25 /usr/share/racket/collects/setup/parallel-do.rkt:441:20: loop

Can anyone help with issue?

Why echo "a" first?

Probably to install all. But there’s a better way: use --auto

Ah.

Yup. echo "a" just answer the question install y/n/a .." when you runraco pkg install`

So I have isolated the problem to the package relation . When I remove this package, the installation went just fine.

I did not know abut --auto . It is probably a better way to install

What happens if you raco pkg install --auto reprovide-lang?

let me try

Same issue arised!

The pkg reprovide-lang installed correctly. Afterward, I installed pkg relation and hit the same error.

I have submitted a bug report on github.

See https://github.com/AlexKnauth/reprovide-lang/issues/14

Looks like it only affects some systems

A little progress: I have no separated the gui dependent parts of #lang sketching into a separate module.

The “main.rkt” file for #lang sketching behaves normally when it contains: #lang racket/base (require "exports-all.rkt") (provide (all-from-out "exports-all.rkt")) When I change it to: #lang racket/base (require "exports-no-gui.rkt" "exports-only-for-docs.rkt") (provide (all-from-out "exports-no-gui.rkt" "exports-only-for-docs.rkt")) Then raco setup can build and render the sketching-doc which consists of the file “manual-sketching.scrbl”.

But … how do I make the switch from “manual-sketching.scrbl” ? If I make a new language, say, sketching-no-gui wouldn’t that confuse Scribble, when it looks at the binding information?

Scribble follows require chains and uses the first (re-)providing module it finds that documents a binding.

On the documenting-bindings side, the defmodule form has a #:use-sources option to list preferred modules to counts as ones providing a binding (in cases where those modules are in the providing chain). When documenting the sketching module, you may need to specify the exports-no-gui module as the preferred source in that sense. Then, a traversal from sketching-no-gui will hit the provider exports-no-gui. (Or something like that.)

I was also buiding inside docker. Perhaps it only affects build inside docker container. The image I am using is debian.

Thanks again @sorawee. I have reported the issue to github and included the link to related issue.

I sometimes need to add info.rkt in subdirectories to specify compile-omit-{files,paths}. But other than that I always have info.rkt at the root of each package.

Maybe there is some notion of “project” in Vim (or a popular Vim plugin) that you could ride on top of?

On the Emacs side I’ve found that to work well in practice. There’s a built-in “version control project” thing; there’s also a popular package called “projectile”. So you could delegate to them, just ask “what’s the project root for this file?”, and let them deal with the messy ways of defining that (including letting users tweak that). Often there’s some last resort escape hatch where e.g. a user could create a .projectile file in the project root, if there’s not otherwise something like .git or whatever to look for.

At the same time, I think you’re right that things like drracket/check-syntax are currently very much single-file, and you give them a complete/absolute path to that single file. So it probably won’t matter much if they’re part of a “project” or not, and also won’t matter what the Racket current-directory is (IIRC check-syntax will parameterize those as-needed from the file’s compete path).

Unfortunately the “project” world in vim is fairly limited. There are a number of plugins that give you different things. But no standard. (And of course, plugins cooperating happens, but it’s usually a side/after thought. They like to be independent. So I couldn’t ask ALE to exclusively define a project root via a plugin.) I thought about also looking for .git, but I figured I would stick with info.rkt and fall back to the pwd if not found (since I always open vim from the project root).

I might be able to look for the highest directory containing info.rkt, instead of lowest? And use pwd as fallback.

We are using v7.9. We could try upgrading. This is on a non-technical developer machine so they install from the site.

Out of curiosity: are there currently any plans for a RacketCon 2021? And if so, is it decided if it will be an in-person or virtual event?

Upgrading does make sense as a first step. The default v8.1 is CS (which is a very different beast, of course). Besides whether upgrading solves the problem, it would be interesting to know if there’s any difference between v8.1 CS and v8.1 BC. For example, a STATUS_HEAP_CORRUPTION error might have something to do with the way the BC implementation manipulates the C stack, and the CS implementation doesn’t do that..

Tentative plans: virtual in early October