I have a Typed Racket question, if anyone could help I’d appreciate it. I’d like to have a pattern matcher with exhaustion checking, like in ML, so I can be confident that I’m not omitting any cases. Does anyone know of such a pattern-matching macro?
If not, would anyone have pointers for how to get to the type information I’d need, from a macro, so I could make a go at writing something to scratch my own itch?
@notjack Fair. It just seems to me that having a separate test-dep list and doc-dep would make sense.
Because I could be installing in a context where I don’t care about installing the tests. And right now (as far as I can tell), the only way to do that is to make multiple packages.
The whole foo foo-lib foo-doc foo-test foo-extra thing.
(Which I guess makes sense for some dependency resolution, but still feels clunky to me in this simple case.)
Thank you for the technical terms I can now look up!
@tfb match is the most commonly used pattern matcher in Racket — unfortunately Typed Racket cannot reason about its coverage, since it can expand into quite complex core forms. there was recently a discussion (https://github.com/racket/typed-racket/issues/594) about getting some straightforward coverage checking working. if you’re interested in tinkering with your own approach solution, I threw together something along that line a while ago (https://github.com/pnwamk/datatype), but it’s definitely not a polished, drop in solution (i.e. it works but is limited and does not work with arbitrary types, you have to define them similar to defining an algebraic datatype in a standard statically typed functional language)
there may be some other approaches people have put together as well, I’m just not familiar with what they are off the top of my head
@florence @stamourv @robby Have you had font issues with your submission?
I seem to have tracked it down to \renewcommand{\rmdefault}{ptm}
Which really messes up the lower case g
.
That command chooses a font
Like the whole font, I believe
Yup. But scribble/acmart
seems to put it in there.
At least as far as I can (currently) tell
Would it makes sense to remove that?
@leif scribble/acmart should not generate Tex code like that I agree. That should be in the cls file.
But I am confused. If that had any effect it should have set the font to the standard latex roman font. And I don’t see that in our paper
Maybe it just messed up the state in some more subtle way?
I think binary installs from the build server let you skip installing build deps
That….is a very good point. :confused:
Like, it certainly does look different than the standard computer modern font. But there are also similarities to times. SO I honestly have no idea.
Sure, that makes sense.
But I can still see a case where I want to build the docs, but I don’t want to run the tests.
Removal of that line seems wise
Or I want to run the tests, but don’t care about building the docs.
Ya, that’s the only way I was able to get rid of it. Unfortunately the line is in the main scribble.tex style file. So its not just as simple as removing it from acmart. :disappointed:
You can get the pre-built docs without tests currently (—binary vs —binary-lib) but yeah, there’s no way to get runnable tests without building docs
Maybe a different kind of installation that was like --binary
but included compiled test modules?
building docs without running tests could just be running raco setup
right?
‘You can get the pre-built docs without tests’ Yes, but say I don’t want the pre-built docs, I want to build them myself.
Say I’m making my own language that has its own theme for docs. And I’m using that library. I want to provide the docs for the library in the new format, which means getting the source, but I don’t care about building the tests.
If that makes any sense anyway.
Oh ya, building docs without building tests is easy, same as building tests without docs.
The problem is just with dependency resolution.
As the two are tied together.
How does making scribble docs with custom themes work anyway?
Uhh…depends on what you want to change.
The easiest thing is to just change the css file.
(Which honestly wouldn’t really require getting the source.)
The other way is to take the doc
structure scribble files provide, and munge it the way you want.
IIRC, frog does the former.
What about if you want only docs for certain packages to look different? Like say we wanted all docs for Typed Racket packages (including libraries people wrote providing things for TR) to have a different visual theme of some sort
reply_broadcast messages not yet supported
That’s easy if you have the source. Just change the style the doc uses.
(AKA, point the doc to its own css file.)
ah so you’re referring to changing all docs globally for some set of packages to use a new style as a consumer of those packages, not an author of them? like how the http://docs.racket-lang.org\|docs.racket-lang.org sets the logo for all docs?
I didn’t catch that, my bad