@notjack can’t seem to reproduce the issue. Maybe it depends on the libraries you use?

Nonetheless, feel free to use another image if it solves your problem.

@krismicinski I don’t think there’s been much work on that

There’s some code to check that in the optimizer, of course, as well as in the linklet extractor in the expander

Who do I report to about the lack of accessibility with screen readers and dr. Racket?

@hunter.t.joz you can report issues on http://github.com/racket/racket\|github.com/racket/racket, @leif is likely to know more about screen reader use

@hunter.t.joz Some weeks ago I think @leif was trying to improve accessibility for screen readers, as far as I know.

A question about flat contracts, in my particular scenario I need to make sure flat contracts can be directly used as functions since they may be plain Racket values pulling double-duty so I check to see if they satisfy procedure? or not and report an error accordingly. I wasn’t happy with that so I was poking around the documentation and found flat-contract-predicate which would allow me to handle all flat contracts the same way. The accompanying note warning it exists for backward compatibility gave me pause. Is there a better way to cope with flat contracts that may be predicate procedures or not? Basically I’d like to take arbitrary flat contracts and apply them as predicates without worrying about what kind they are.

@abmclin All flat contracts are predicates now, so you can just apply them as functions.

@lexi.lambda as @abmclin notes, that’s not true

use flat-contract? and contract-first-order-passes?

Oh, you’re right, I misinterpreted.

(flat-contract? 7) is #t

There’s a way to coerce something to a contract, right? Does that do the right thing here?

I think those docs should just be changed

coerce-flat-contract

Does coerce-flat-contract produce a procedure when given a literal?

agreed, one section encourages you to use flat-contract-predicate while another section seems to say beware, so that function would be so useful so would be nice if it was more blessed

It looks like coerce-flat-contract doesn’t do what you want; it passes non-procedures through unchanged.

no, that’s just the printer lying to you

I was confused by that too

ok it seems it is perfectly ok to use flat-contract-predicate? And just remove the note about backward compatibility as unhelpful?

that’s my feeling

contract-first-order-passes? looks interesting, it would simplify some of the code involved in verifying whether a contract accepts the value or not

the first order thing gives me heebies jeevies though, is there such a thing as second order?

nope just higher order

the idea is, if ctc is a first-order contract then (ctc v) either returns v or raises an exception … it doesn’t return some chaperoned or modified version of v

ah ok, and flat contracts are always first-order?

yes

I’d say, flat contracts are only first order. Chaperone contracts are first order + some other things

ok that was helpful, thank you

cool

(contracts like or/c use this first-order-passes check to decide what contract to apply to an incoming value) EDIT: maybe it’s only or/c? I can’t think of another

still interesting to know, I like the contract system a lot

using a conjunction of flat-contract? and contract-first-order-passes? has solved my problem and simplified some things as well so I’m happy with it.

@samth huh

> (coerce-flat-contract 'here 42)
42
> ((coerce-flat-contract 'here 42) 1)
#f
> (number? (coerce-flat-contract 'here 42))
#f

I would expect contract-name to produce 42, but I did not expect it to print as 42…

It trips me up sometimes, guess it’s a way of being helpful in telling you what values satisfy the contract

afterall plain values are already contract? true so it makes sense that any contract wrapper would print its underlying plain values

I’m not sure I agree… I’d much prefer a printing style like #<flat-contract: 42>. but oh well.

it’s interesting how structs assume many disguises in the Racket ecosystem

I think the model is that every value is supposed to be a “structure” with possibly opaque fields

so it’s not so much that structures are a lot of things but that everything is a structure. (of course this isn’t actually true, but all the structure functions work on arbitrary values and treat non-structure things the same as opaque structures for this reason.)

e.g. > (struct-info 42) #f #t

makes sense, I can see how that model would be convenient for attaching all kinds of metadata or functionality to any values to help support Racket’s programmable programming language features. Or at least allow values to be treated in a uniform manner.

it looks like contracts in general print as contract-name, which usually makes sense… it just does a sort of weird thing in the case of the class of flat contracts that are represented by plain values.

@mflatt Did the way subprocess subprocesses handle io ports change in Racket 6.10?

though that’s not entirely true… the printers installed by make-contract and friends use the #<contract: ...> convention. but it looks like the combinators from racket/contract have their own convention.

I ask because we have a program that effectively prints out a line of text and finishes, which works correctly when called from Racket 6.9 or below, but fails on 6.10 up. (Or rather, it deadlocks and the string never gets printed to the port.)

@leif v6.10 was the switch to rktio, so something may have gone wrong there

Do you have something that I can run?

Uhh….kind of, but it has a lot of odd deps.

(Trying to shrink it down now, but its written using: https://github.com/vasilisp/inez)

With this file:

open Script ;;

let x = fresh_int_var() ;;
constrain (~logic (x >= 0)) ;;


constrain (~logic (not ((0 <= (x - 1)) && ((0 = 0) && (0 = 0))))) ;;

solve_print_result();;

But its kind of complicated to set all of it up. :disappointed:

Justin Sleapak has it running on his computer.

Slepak*

@mflatt Okay, I have failed to make a program with the same problem. So Jusin is just going to package his up into a VM and send it to you. Would that work?

ok

@abmclin @lexi.lambda @samth how about contract-first-order?

oh I saw contract-first-order-passes?

@shu—hung yes it did the trick for me

I just had a situation in which I got a strange error from Racket relating to units that went away after wiping out compiled/. Am I correct in saying that this is probably a bug? Might be tough for me to replicate and minimize but will keep in mind. It was a vector-ref contract violation, which I think means that racket units are packing things into vectors, the spec changed, but Racket was using stale code and then that was causing a contract violation.

Didn’t really occur to wipe out compiled until I realized this might what was happening..

@krismicinski it’s maybe a bug but also maybe not

Yeah, I don’t know enough about units or the implementation to say tbh. Probably I just should have anticipated that..

it’s almost certainly because of stale compiled files, which can cause errors

whether that error is the sign of a bug is hard to say