hello, I am looking for a function (-> contract? any/c boolean?) that checks if a value satisfies a contract, is there such a thing?

That’s in general undecidable, right?

how so?

E.g., when the contract is a function contract, and the value is a function value.

Then you are asking about the behavior of the function

And this easily becomes the halting problem.

Ah ok, yes of course

So the kind of implementation I had in mind was something that looks like (define/contract (check v) (-> my-contract/c void?) #t)

where my-conctact/c is a parameter and the contract error is caught and instead of it #f is returned etc, I think the point is clear though

So, there’s a class of contracts that’s flat. These contracts are immediately checked, and you can use them as predicates too

See https://docs.racket-lang.org/reference/contracts.html#%28tech._flat._contract%29

Does that work for your purpose?

E.g.,

(define (flat-contract-satisfies? c v) (c v))

yes that’s exactly what I wanted but hash/c is not a flat contract :disappointed:

the contract I wanted to check was a hash/c

Where does hash/c come from? Are you the person who writes it?

hash/c could be flat by providing it the option

yes, I have this contract that is (define path/c (hash/c symbol? (sequence/c or-group/c))) and I want to test that it works for some values

Are you able to be more specific w/ the contract? For example, I think hash-eq? is a flat contract.

yes! thank you

I am assuming there is no flat contract variant for sequence/c

looks like flat contracts are directly callable, nice

Yeah. sequence in general could be infinite, so I think flat contract wouldn’t work well there.

I used list/c for now and I will worry about it some other time

thanks @sorawee, much appreciated

You probably want listof, I think.

Well, I guess it depends on what you want to do.

what’s the difference?

(list/c number? boolean? number?) recognizes (list 1 #t 3)

(listof number?) recognizes (list 1 2 3)

excellent, thank you

is this test expected tor run for more than 20 mins (it started 20 mins ago, and it is still running) raco test: "/home/capfredf/code/racket/racket/share/pkgs/../../../pkgs/racket-benchmarks/tests/racket/benchmarks/shootout/k-nucleotide.rkt" raco test: @(test-responsible '(eli jay mflatt robby samth stamourv))

is there a require ish statement that I can run on the REPL to run the tests of a submodule, something along the lines of (force-require (sumbod "path.rkt" types-submod cheap-tests))

?

I want to like JavaScript but I’m bothered by all the extra equal signs and curly braces.

Here it takes about a minute: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/racket.html

raco test has a command-line flag for a submodule to run.

I think -m?

I’ve been reading through David Flanagan’s “JavaScript: The Definitive Guide” 7th ed., and JavaScript has much improved over years ago :) Still doesn’t hold a candle to Racket IMO, but the improvements are welcome for when I need to enhance a web app. I’ve realized I no longer need jQuery since native JS does everything I need now in ES6+

I would prefer the tests to be run in the repl… If it’s not possible I will probably resort to that

Nope it’s -s.

If you’re using Racket Mode you can put point inside any submodule form and C-c C-c to run that submodule.

From an edit buffer. That’s not “in the REPL” tho.

I did (require (submod (file "/path/to/file.rkt") types-submod cheap-tests)) and it works but it doesn’t run the displayln statements in the top level of cheap-tests

I’m not sure off the top of my head. (FWIW I usually have a Makefile for tests, and sometimes slow or extra tests get their own target and use that raco test flag to run a submodule. And then M-x compile make xxx.)

It’s just syntax. You get used to it. You can also (mostly) make your tooling take care of the syntax for you to focus on semantics.

It’s not just syntax. It’s also the split between commands and expressions.

I’m kind of confused how doing the require doesn’t result in the displayln.

You are right the cursor in the module does the trick, nice!

But still I find it surprising too

I meant the === and the curly braces.

Ah! I think Greg is partly joking :slightly_smiling_face:

Makes sense.

I am not 100% sure…

Thanks for the information

Probably it’s already been required

@alexharsanyi I am running raco test -p plot-test , and I am getting a lot of test failures like: GNATS#13620: stacked-histogram loops when given an empty list of labels > gnats13620-contour-intervals FAILURE name: fail location: /home/capfredf/code/racket-extra-pkgs/plot/plot-test/plot/tests/helpers.rkt:210:4 params: '() message: "draw steps not the same, new set written to /home/capfredf/code/racket-extra-pkgs/plot/plot-test/plot/tests/PRs/./test-data/new-gnats13620-ci.dat" -------------------- -------------------- GNATS#13620: stacked-histogram loops when given an empty list of labels > gnats13620-contour-intervals3d FAILURE name: fail location: /home/capfredf/code/racket-extra-pkgs/plot/plot-test/plot/tests/helpers.rkt:254:4 params: '() message: "draw steps not the same, new set written to /home/capfredf/code/racket-extra-pkgs/plot/plot-test/plot/tests/PRs/./test-data/new-gnats13620-ci3d.dat" -------------------- I haven’t made changes to plot-test. I am testing changes to rackunit. The racket I’m using was built from source (f856aa). Am I missing anything? Do you have any ideas why those tests failed?

Ah sorry I was trying satirize people complaining about “all the parentheses” and flip that around. :smile:

Although === is genuinely hilarious; JavaScript, the good equality operator. :wink:

This message indicates that the drawing of the plot has changed. There were some recent changes to the draw library, which means that the latest plot package tests only pass with a recent snapshot build of Racket, but not with 8.3. There is a recent commit by Alexis King about this.

I didn’t make myself clear. I am using 8.4.0.3

What I can suggest is to check the difference between draw steps to determine what might be wrong. You should have a new set of .dat files generated as part of running the tests. and you can use the the utility functions in the plot test to read them. They are gzip compressed sexp files.

I see. But anyway, thanks for your confirmation. it seems like those errors are not caused by the changed rackunit. (I ran those tests with the unchanged rackunit and those errors remained)

Those tests are meant to catch the situation when the plots would change in a visible way. They are more likely to fail for changes to the plot package or changes to the draw package. Of course the tests themselves might have bugs…

Another possibility is font differences

The plot tests will account for font differences and should not fail on different platforms… unless there’s a bug in that code as well