joelmccracken: it doesn’t matter

thanks sir

The only way it matters is if you expect the argument to embed/url to return

because they all return to the same s/s/d

ah; didn’t realize that was possible! I don’t really understand what that would do, lol

joelmccracken: here’s an example https://github.com/racket/web-server/blob/master/web-server-lib/web-server/default-web-root/htdocs/servlets/examples/add-ssd.rkt

oh wow, that’s nuts. thanks. I might use this feature

I have a weird bug in a large program due to subprocess I/O that affects Racket 6.10 only

I understand there was a big rewrite for that version.

Can anyone here help diagnose and work around it?

I’ve gone about as deep as I think I can without entering the Racket internals.

can you isolate the problem into a short section of code and post that?

Unfortunately, I haven’t, and in fact the bug is quite finicky

It seems to depend, for example, on weird timing choices.

This bug, from a friend, seems related: https://github.com/racket/racket/issues/1769

It also has to do with juggling multiple Z3 processes and killing some of them.

@pavpanchekha Can you reproduce the bug on a nightly snapshot? https://plt.eecs.northwestern.edu/snapshots/

@lexi.lambda Working on it

The bug does not occur on nightlies

So looks like it will be fixed when the next version of Racket 6.10 comes out. Thanks all!

@pavpanchekha: There are no planned updates for 6.10. The fix will most likely be in 6.11, which is scheduled for late October.

Ok, great!

For defining contracts on functions, is it generally preferred to use contract-out over define/contract? It seems like contract-out is more popular, and I’m curious what the reasoning is for this. If you already know the domain and range of a function, is there any benefit to pushing the contract definition out to the module boundary?

Having the contract right there in the function definition seems more readable, doesn’t it?

it does, which is why I ask :slightly_smiling_face:

Contracts can have a non-trivial performance overhead that you may not want to incur wherever a function is used within a module, whereas it’s more likely to want to protect a function from invalid inputs that come from other modules

I’m using define/contract right now to debug something. I might remove them, or convert them to module level contracts when I’m done

contract-out turns the function exported into a macro that can pick up information about the module it’s used in, so contract errors tell you both which module the contract is from (the module that used contract-out) and the module that misused the function.

also, when using contract-out, you can skim the first few lines of a module to get a sense of what functions it exports and what they do instead of having to dig through the entire module looking for contracts and function signatures

philosophically speaking, a module is a single “unit of trust” so it doesn’t make sense for it to guard against inputs from itself (as define/contract would)

(unless, of course, you have buggy code to fix, or maybe i just am a poor racketeer)

that’s a valid point. I think the counter argument is that contracts are not meant for debugging :)

Thanks, that’s a lot of good info! And yeah, I’m basically building something from scratch and want to make sure I get good error message when I accidentally violate my assumptions as the code evolves over time. But it sounds like you actually get better error reporting when you do it at the module level, so I’m inclined to stick with that.

oh have you seen the debug package? it’s a really, really good debugging tool to be aware of

yeah i’m not sure how to debug this web server stuff,

i feel like youre about to be my hero after I look it up

I haven’t seen it, I’ll look into it. Thanks!

not the one from the mischief package, which should probably be considered deprecated

https://docs.racket-lang.org/debug/

nice.

does racket have the ability to specify/lock versions of packages? you used to be able to include the planet specs directly in a file

nope, packages also can’t declare that they depend only on a specific range of versions of another package

this is an area that needs more work..

you also can’t install different versions of the same package

interesting

that’s one word for it

(that it was removed, since it used to work)

planet let you do it but you had to specify the version in source code of every module that used the dependency

(maybe i’m misremembering though)