I am attempting to make a small change to DrRacket.

1. I forked the drracket repo on github
2. I downloaded a snapshot from https://snapshot.racket-lang.org/
3. I cloned my drracket repo to my local machine in the folder drracket-home-end Now I need to build DrRacket from the copy in drracket-home-end. So I now link all the drracket folders:

/Applications/Racket\ v8.0.0.12/bin/raco link drracket /Applications/Racket\ v8.0.0.12/bin/raco link drracket-plugin-lib /Applications/Racket\ v8.0.0.12/bin/raco link drracket-test /Applications/Racket\ v8.0.0.12/bin/raco link drracket-tool /Applications/Racket\ v8.0.0.12/bin/raco link drracket-tool-doc /Applications/Racket\ v8.0.0.12/bin/raco link drracket-tool-lib /Applications/Racket\ v8.0.0.12/bin/raco link drracket-tool-test

Along the way I have set PLTNOTOOLS=1 .

Now I run /Applications/Racket\ v8.0.0.12/bin/raco setup drracket The output is long, but the problem is that along the way <pkgs>/drracket-plugin-lib/dracket is being built instead of the one in drracket-home-end .

What am I missing?

raco setup: version: 8.0.0.12 raco setup: platform: x86_64-macosx [cs] raco setup: target machine: ta6osx raco setup: installation name: snapshot raco setup: variants: cs raco setup: main collects: /Applications/Racket v8.0.0.12/collects/ raco setup: collects paths: raco setup: /Users/soegaard/Library/Racket/snapshot/collects raco setup: /Applications/Racket v8.0.0.12/collects/ raco setup: main pkgs: /Applications/Racket v8.0.0.12/share/pkgs raco setup: pkgs paths: raco setup: /Applications/Racket v8.0.0.12/share/pkgs raco setup: /Users/soegaard/Library/Racket/snapshot/pkgs raco setup: links files: raco setup: /Applications/Racket v8.0.0.12/share/links.rktd raco setup: /Users/soegaard/Library/Racket/snapshot/links.rktd raco setup: main docs: /Applications/Racket v8.0.0.12/doc raco setup: --- updating info-domain tables --- [11:17:45] raco setup: --- pre-installing collections --- [11:17:45] raco setup: --- installing foreign libraries --- [11:17:45] raco setup: --- installing shared files --- [11:17:45] raco setup: --- compiling collections --- [11:17:45] raco setup: --- parallel build using 8 jobs --- [11:17:45] raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/browser raco setup: 6 making: <pkgs>/drracket-plugin-lib/drracket raco setup: 6 making: <pkgs>/drracket-plugin-lib/drracket/private raco setup: 5 making: <pkgs>/drracket-tool-lib/drracket raco setup: 4 making: <pkgs>/drracket/drracket raco setup: 4 making: <pkgs>/drracket/drracket/private raco setup: 5 making: <pkgs>/drracket-tool-lib/drracket/private raco setup: 5 making: <pkgs>/drracket-tool-lib/drracket/private/syncheck raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/browser/private raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/browser/tests raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/drracket raco setup: 4 making: <pkgs>/drracket/drracket/private/syncheck raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/drracket/private raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/drracket/private/syncheck raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/drscheme raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/drscheme/private raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/gui-debugger raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/gui-debugger/icons raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/help raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/help/private raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/macro-debugger raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/repo-time-stamp raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/scribble raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/scribble/tools raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/scribble/tools/private raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/scribblings raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/scribblings/drracket raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/scribblings/tools raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/setup raco setup: 7 making: /Users/soegaard/drracket-home-end/drracket/drracket/version raco setup: --- creating launchers --- [11:17:48] raco setup: launcher: /Users/soegaard/Library/Racket/snapshot/DrRacket.app raco setup: launcher: /Users/soegaard/Library/Racket/snapshot/bin/drracket [script-cs] raco setup: launcher: <gui-bin>/DrRacket.app raco setup: launcher: <gui-bin>/bin/drracket [script-cs] raco se

Don’t use raco link.

To replace a package, you need to use a raco pkg command. In this case, I think you want raco pkg update --no-setup drracket/ (the trailing slash matters) for each package, and then raco setup should do the right thing.

The raco link command works at the level of collections, and it doesn’t remove the registration of existing packages. Meanwhile, raco pkg … assumes that is gets to manage links for a package, so you shouldn’t try to manage links for package collections.

Makes sense. I have removed all links and cloned my forked drracket repo to a new folder. Now I run into:

soegaard@mbp2 drracket-home-end2 % /Applications/Racket\ v8.0.0.12/bin/raco pkg update --no-setup drracket/ Inferred package scope: installation Updating: drracket raco pkg update: package conflicts with existing installed item package: drracket/ item category: doc item name: "drracket-tools"

Is drracket/ the repo clone, or is your current directory set inside the clone? In the former case, you’ll want to use drracket/drracket/ to refer to the package directory within the clone.

(I get the error you report if I try to install the repo as the package instead of the drracket directory within the repo.)

I’ll try drracket/drracket/.

In your screen shot above, you’ve cded into drracket, so from there you’d just want drracket/ after all.

Thanks - it works now.

I’m trying to run scribble --dest dest/my-document/ --dest-base ../common/ --html path/to/my-document.scrbl. It correctly puts the extra files in dest/common/, but it doesn’t inject a <base href="../common/"> tag at the top of the HTML. I tried adding my own with a js-addition which writes the tag, but that comes after the scribble.css and scribble-manual.css.

How do I add a <base …> tag right at the start of the <head> (or at least before any external stylesheet or script is included)?

It looks like scribble is confused in its use of --dest-base. That option was originally added to support LaTeX rendering, and the HTML rendered was not fully adapted. Also, the “base” in the name is kind of a coincidence; it wasn’t meant to have anything to do with <base>, and was meant to be a string prefix instead of a path.

Internally, there’s an option to map files like “scribble.css” and “scribble-manual.css” to alternate paths, but that isn’t exposed at the command-line level.

I will look at fixing up --dest-base, at least, by having the generated references use that prefix and making sure it works right when it’s a path.

Meanwhile, there doesn’t seem to be a way to add to <head> before other things. (The head-extra style property adds to the end.)

Thanks :slightly_smiling_face:

I got a workaround working by adding <base …> as early as possible (in the title’s #:style), and re-adding the elements that are above. I copied those elements by hand (I guess I could also automate that directly in the browser with a bit of JS). However the browser attempts to load the elements before that <base …> which could cause undesired behaviour.

Also got a workaround by changing the prefix in html-defaults, but that allowed me to add the <base …> right after the doctype, before the <html> and <head>, which is not quite right.

In both cases, the result seems to work fine, including for dynamically-injected scripts (for some reason I have some scripts which do document.write('<scr'+'ipt src="…"></scr'+'ipt>'), not sure why I did that, but regardless of the reason it works fine with <base …>).

I’ve run into a weird bug with an in-place install of Racket; Racket won’t launch if i use ~ in my path to it, it seems. When I set my path as export PATH = "~/racket-v8/racket/bin:$PATH", launching racket gives the following error: $ echo $PATH ~/racket-v8/racket/bin: $ which racket /home/c/cs-411/racket-v8/racket/bin/racket $ racket Welcome to Racket v8.0 [cs]. standard-module-name-resolver: collection not found for module path: (lib "racket/init") collection: "racket" in collection directories: /home/c/cs-411/.racket/8.0/collects However, if I export PATH = "$HOME/racket-v8/racket/bin:$PATH", racket works: $ echo $PATH /home/c/cs-411/racket-v8/racket/bin: $ which racket /home/c/cs-411/racket-v8/racket/bin/racket cs-411@valdes:~$ racket Welcome to Racket v8.0 [cs]. > Any advice? Clues?

You can’t use literally ~ in PATH. Normally, ~ is expanded away by your shell, as in laptop$ echo ~ /Users/mflatt It’s not expanded by things that parse PATH.

The shell won’t expand ~ in quotes, but it will expand $HOME in quotes: laptop$ echo "~" ~ laptop$ echo "$HOME" /Users/mflatt

Oh okay. But then, why does racket start to launch before falling over?

Hm… it could be that your shell behaves differently than mine, and it does expand ~ when parsing PATH. In that case racket and the shell disagree on the semantics of PATH.

I don’t think ~ should be expanded when parsing PATH, and it seems like my shell doesn’t do that, but I could be mistaken.

Okay that kind of makes sense. This shell is bash, and I’m never sure about bash semantics

Thanks!

I see that bash does behave that way on my machine. That’s surprising.

Should ask Michael Greenburg about the correct behaviour.

Hi, the docs for math/array mention degraded performance when used from untyped racket due to contract checking. It’s also written “we are working on it”. I’d be most interested to help with that (although not sure I’m good enough). Can someone here maybe tell me a bit more precisely what the issue is and what has been done about it (or point me towards previous discussions)?

@raoul.schorer I’ll dig something up. The comment is old - Neil Toronto worked on it, but he isn’t doing much with Racket now (as far as I know).

https://groups.google.com/g/racket-users/c/oo_FQqGVdcI/m/p4-bqol5hV4J

https://groups.google.com/g/racket-users/search?q=array%20neil%20typed%20untyped

Also @samth is the man to ask.

If you just need floating point matrices, look at flomat instead.

Thanks, I’ll try to understand more about it and see what I can do

@soegaard2 So, I gave it only a cursory read for now but my first intuition is that “shallow typed racket” could maybe be part of the solution, wouldn’t it? In my understanding, this would perhaps alleviate much of the contract checking burden.

My understanding is very limited wrt this issue. I think @samth can give a better answer.

I ran into a behaviour change with unsafe-fx+ and friends that I’m curious about: I think previously, if I gave it booleans, it would give me back a fixnum (as expected). But now it seems to give me #<garbage> or #<foreign> or #<unbound object>; how does it do this, rather than just returning some bits that render as a fixnum?

As far as I know, not all 8-byte bit patterns are valid floating point numbers according to IEEE 754. This may explain the weird results.

This should be a fixnum, not a flonum.

Sorry, yes, I confused this. I had thought that I had used unsafe-fx+ for floats, but now I remember I used it for integers. :smile:

That said, the documentation at https://docs.racket-lang.org/reference/unsafe.html says: “If arguments violate an unsafe function’s constraints, the function’s behavior and result is unpredictable, and the entire system can crash or become corrupted.” So the unexpected behavior is to be expected. :wink:

Sure. I’m just curious about how it’s not just giving me an arbitrary fixnum.

Guessing: The function gets a part of a non-fixnum and interprets it as a fixnum, and what you’re seeing is a combination of the unused part(s) of the argument(s) and the result that comes directly from the unsafe operation.

But of course it would be good to get an answer from someone more knowledgeable. :slightly_smiling_face:

@wjb BC vs CS? In BC, unsafely adding a non-fixnum to a fixnum will generally (always?) produce a fixnum. In CS, unsafely adding a fixnum to a non-fixnum will generally not (never?) produce a fixnum. The difference between BC and CS is in the way the lower bits of a pointer/fixnum are used as tags.

Okay, and the tag bits get mangled into (arbitrarily), something that the printer happens to know about?

In BC, a 1 as a low bit means fixnum, so adding a fixnum to non-fixnum leaves a low bit set, meaning a fixnum. In CS, 0s for the low three bits means a fixnum, so adding leaves a non-fixnum tag; all 1s in the low three bits means a pointer to an object that starts with a second-layer tag, and that’s where the variation comes in.

Right. I ran into it while teaching pointer tagging, and my course follows Chez’s tagging scheme. I was just surprised at what the printer rendered and wondered if it was intentional or accidental. #<garbage> looks almost like it was doing some kind of dynamic check … which didn’t make sense.

There was a dynamic check in the sense of a dispatch in the printer. If you have an “immediate” like a boolean, (void), null, etc., the low three bits are 110, and there’s a lot of unoccupied address space in that category. Probably you’re seeing #<garbage> for something that has the bit pattern for immediates but doesn’t match one of the subcategories. But it could also be an unrecognized secondary tag.

makes sense. thanks.

Is there any mechanism to combine .zo files or multiple .rkt files into a single .zo?