@ryanc opened an issue here https://github.com/racket/macro-debugger/issues/23

@mflatt cool, thanks.

BTW, does anyone know of a good way to write tests for DrRacket plugins?

About all I have so far is to keep as many of the smarts as possible out of the plugin, and then just not test the plugin.

@leif There’s extensive infrastructrue for testing DrRacket

@samth Perhaps I’m looking in the wrong place. Because I’m not seeing anything about that in the DrRacket plugin’s manual: http://docs.racket-lang.org/tools/index.html?q=drracket%3Atool%40

Like, I see stuff about making drracket tools for debugging

And elsewhere I can see tests for the drracket plugin infrastructure.

But I don’t see anything about writing tests for DrRacket plugins.

what’s up with the acmart package? it has a version exception pointing to scribble-lib?

@notjack Ya, @fahree and I had a package going on the catalog. Then DVH added a collection to scribble-lib for scribble/acmart, thus conflicting with the existing package (and also being incompatible too. :disappointed: ), so we cleaned it up to make it inline with the existing package (and scribble conventions).

But we wanted to leave the acm package up there because it was still useful in old versions of racket.

Although I am glad DVH merged it into scribble-lib. And to be fair, he did ask if anyone else had done it first. But I didn’t find out about it until it was too late. :slightly_smiling_face:

@leif the build server does not seem happy with this arrangement :p

Although I guess the other moral of the story is…check the package server before putting something int he main distro?

@notjack ha, ya, I guess it would: http://pkg-build.racket-lang.org/server/built/fail/acmart.txt

Hmm…I guess we could just have acmart be a completely empty package.

(In everything but racket 6.8)

version exception pointing to totally different package seems like it could have lots of strange consequences

empty package does seem better to me

(I gotta write stuff like this down for a future doc about good racket package practices)

While I agree, I do kind of think that this could also just be resolved by having a cleaner package system.

(magically cleaner…. I don’t want to put myself on a burning steak….err.design it. :wink: )

no disagreement here

the specific case where package A depends on B and provides module X, then a new version of B also provides X, seems worth taking a look at though

I could see that coming up a lot both by accident and as a result of people deciding that X really belongs in the core and moving it into B from A by choice

Yup

So, right now the best I got is we should use c like conventions…

that is, only provide collections with a unique identifier.

Kind of a sad idea given how nice things like…ya know…scope, is.

But….again….its what we got, and I don’t have a better idea.

(Nor want to spend the energy to come up with one right now.)

1) versioning packages and 2) extending the “version exception” idea to packages other than “main-distribution” seems like a decent way to do it

That solves a lot of problems, but not all of them.

Because a package can have multiple collections, and the collections are cross cutting through multiple packages, it also should have a unique collection name.

I don’t think you need to use a unique identifier

Racket is small enough that just “avoid conflicts” seems like enough at the moment

Haskell is much bigger, and it mostly avoids conflicts despite the hierarchal namespace. However, GHC has a much nicer story around collisions (it knows about some low-level notion of packages, so you can alias or hide packages as necessary, and you can also specify the package when importing if absolutely necessary).

@mflatt @robby In my language, . is a valid identifier. Is there any way to get @racket[\|.\|] to typeset the . without the vertical bars? Or will I need to either make a custom version of the racket/racketblock/etc. forms or use unsyntax to escape to @racketidfont{.}? It would be nice to not have to reimplement the whole universe of typesetting functions, including the scribble/example forms.

Reimplementing the entire universe does sound daunting.

racketidfont sounds like a good start.

Sorry I don’t have a better answer

@robby Don’t worry. Matthew will have a re-implementation by monday. :stuck_out_tongue:

racketidfont works okay, but it doesn’t work with scribble/example without eval:alts, which is unfortunate.

@lexi.lambda Does something like this help? #lang scribble/manual @(require scribble/racket (for-syntax racket/base)) @(let-syntax ([\|.\| (make-element-id-transformer (lambda (stx) #'(racketidfont ".")))]) @scheme[\|.\|])

@mflatt That gets me a lot closer, thanks! The issue with that is the resulting . is not hyperlinked to the definition of .. I’m looking at the to-element docs, but it doesn’t seem to have a way to use a different element for the content but keep the hyperlink.

It seems there’s probably a more indirect way to get the link target and generate the necessary link element, but I don’t know what it is.

racketlink?

Aha! That should work; I was looking in the wrong section of the docs.

Yes, that works. Thanks for your help.

@mflatt Relatedly, is there any way to override how @defthing[\|.\| ....] renders .? Or do I just need to roll my own definition form for defining .?

I don’t see a good way to adjust defthing