I think that’s normal. The setup command tries to load compiler .zo files to reduce load times and it notices when the .zos are out of date so it then falls back to the .rkt files.

https://github.com/racket/racket/blob/448b77a6629c68659e1360fbe9f9e1ecea078f9c/racket/collects/setup/main.rkt#L291-L302

Could be that there happens to be version bumps between your builds

how do I mandate that the rest-args of a function are nonempty with contracts? #:rest (non-empty-listof graphite-renderer/c) in my ->* doesn’t seem to do the trick

I mean there’s the obvious option of adding a positional argument but…

Are you sure that doesn’t work? Seems fine to me.

I’m experimenting with raco cross. (Thanks, @mflatt ! :slightly_smiling_face: )

As I understand the documentation, there’s no built-in way to get a list of allowed targets, is there? A workaround is to open the web browser at https://download.racket-lang.org/releases/8.1/ and manually check the names of the tgz files for the minimal installations.

I saw that I can install packages for the target platform by (for example) raco cross --target x86_64-linux pkg install data-lib Since I’m already using an info.rkt which contains the dependency, would it be feasible to extend raco cross so that it can install the needed packages (like data-lib in the above example)?

Ok, I tried raco cross --target x86_64-linux setup but that seems to overlook the dependencies for the dependencies in the info.rkt. The output ends with raco setup: --- summary of package problems --- [21:13:48] raco setup: package not installed: racket-doc raco setup: package not installed: scribble-lib raco setup: package not installed: data-lib raco setup: package not installed: errortrace-lib raco setup: --- summary of errors --- [21:13:48] raco setup: error: during making for <pkgs>/sudoku-solver/games raco setup: open-input-file: cannot open module file raco setup: module path: data/gvector raco setup: path: /home/schwa/.local/share/racket/raco-cross/8.1/x86_64-linux-cs/collects/data/gvector.rkt raco setup: system error: no such file or directory; rkt_err=3 raco setup: compiling: <pkgs>/sudoku-solver/games/sudoku-solver/progress-data.rkt raco cross: command failed

Are you saying that “sudoku-solver” declares a dependency on “data-lib”? The installing it with raco cross .... install sudoku-solver (adjusted for or however you reference sudoku-solver) should have also pulled in the dependencies.

No, there’s currently no way to get a list of available platforms. There’s a reasonable path for raco cross to eventually get that information through an installation directory’s table.rktd” and “version.rktd” files (the latter to resolve “current” as a version), though.

hm, it works in the toplevel with a dummy function, but when I > (require graphite) > (require data-frame) > (graph #:data (make-data-frame) #:mapping (aes)) ; hash-ref: contract violation ; expected: hash? ; given: #<procedure:curried:hash-union> ; [,bt for context] despite https://github.com/ralsei/graphite/blob/master/graphite-lib/main.rkt#L33…

(when this call should be a contract error)

I think this is a bug in the contract library. It seems to only be triggered: with contract-out, an optional argument, and an empty rest. Here’s a minimal example: (module foo racket (provide (contract-out [f (->* () (any/c) #:rest none/c any)])) (define (f [x #f] . rst) (void))) (require 'foo) (f)

amusingly I’ve found that this bug doesn’t affect ->i so you can use this contract instead if you don’t want to wait for a bugfix: (contract-out [graph (->i (#:data [data data-frame?] #:mapping [mapping aes?]) (#:width [width (or/c rational? #f)] #:height [height (or/c rational? #f)] #:title [title (or/c string? pict? #f)] #:x-label [x-label (or/c string? pict? #f)] #:x-transform [x-transform (or/c transform? #f)] #:x-conv [x-conv (or/c (-> any/c real?) #f)] #:x-min [x-min (or/c rational? #f)] #:x-max [x-max (or/c rational? #f)] #:y-label [y-label (or/c string? pict? #f)] #:y-transform [y-transform (or/c transform? #f)] #:y-conv [y-conv (or/c (-> any/c real?) #f)] #:y-min [y-min (or/c rational? #f)] #:y-max [y-max (or/c rational? #f)] #:legend-anchor [legend-anchor legend-anchor/c]) #:rest [rest (non-empty-listof graphite-renderer/c)] [result pict?])])

I’ve added a --browse flag for showing a list of available platforms.

very wild macro, but is there a way to parameterize based off of a hash? my efforts so far have gone without success so like, (parameterize-with (hash 'x 3) body) ; => (parameterize ([x 3]) body)

an alternative title for this post is “phase separation is hard”

I would guess if you had a mapping from a symbol to a parameter then it would just fall into place? Maybe something something namespaces

If the keys of the hash were parameters rather than symbols (e.g., (hash x 3) instead of (hash 'x 3)), that could make that part easier.

I think the extent of the macro issue here is just to expand like this:

; =>
(call-while-parameterizing-with (hash x 3) (lambda () body))

Then call-while-parameterizing-with can be defined to convert its argument to an association list, parameterize the first entry of that list, and then parameterize the rest recursively.

I’m not sure that’ll have exactly the same semantics as parameterizing all the entries at once (particularly if you’re dealing with some parameters that were created by make-derived-parameter or make-chaperone-procedure), but it’ll probably work for most situations.

(Particular gotcha scenarios on my mind: Parameterizing multiple make-derived-parameter/make-chaperone-procedure parameters that were based on the same original parameter, and parameterizing multiple make-derived-parameter/make-chaperone-procedure parameters that each have side effects. In particular, if one of the derived parameters has a behavior that depends on the current binding of another parameter, I’m not sure how possible it would currently be to simulate a single multi-parameter parameterize faithfully using a series of nested single-parameter parameterize operations.)

figured it out, at least in my case: https://github.com/ralsei/graphite/commit/a9884449b8cd567e94055a5bbb36fe3f704543b8

ended up having the hash reference the parameter directly

@sorawee Uh oh, the natives are getting restless. Specifically, my students are trying to run files in rosette/sdsl/fsm, and running into an error saying that rosette/lib/lift does not exist. On a whim, I just commented out the rosette/lib/lift require in rosette/sdsl/fsm/lib.rkt, and it appears to “solve the problem” in the sense that fsm.rkt runs without error. Is rosette/lib/lift no longer required? If so, should I make a pull request?

Followup, looks like that file was deleted in c76b803836f89d3bb4 of the rosette repo.

In fact, it looks like that commit removed the uses of define-lift from the fsm/lib.rkt file, but failed to remove the require. Making PR…

@sorawee made PR: https://github.com/emina/rosette/pull/191

> Are you saying that “sudoku-solver” declares a dependency on “data-lib”? Yes, see https://git.sr.ht/~sschwarzer/sudoku-solver/tree/main/item/info.rkt .

> The installing it with raco cross .... install sudoku-solver (adjusted for or however you reference sudoku-solver) should have also pulled in the dependencies. Yes, it did. What surprised me is that raco cross ... install pulls in the dependencies of data-lib, but the command raco cross ... setup doesn’t. If I remember correctly, I installed the dependencies implicitly with raco cross ... install and then thought, since I have defined data-lib already in info.rkt, I should be able to install them with raco cross ... setup , i. e. setup should adapt to whatever I have in my info.rkt (say, if I’d add another dependency in the future).

Thanks!

I’m curious why pkg-build doesn’t complain about the missing module… and perhaps declare-exporting should error when indicated module doesn’t exist