
I made a page on the github wiki to bring some resources together
https://github.com/racket/racket/wiki/Creating-Languages
I’d appreciate it if someone could take a look just to make sure I’ve not made any mistakes.

@spdegabrielle Looks good! Can I suggest adding my recent workshop to the video list? https://fosdem.org/2019/schedule/event/makeownlangracket/

@spdegabrielle Nice! For the https://github.com/racket/racket/wiki/Creating-Languages#lexers-and-parsers section, I wonder if it should instead provide queries for packages tagged as such. That way, it will automatically be up-to-date as packages are added. Also it’s an incentive for people to tag their pkgs well.

Unfortunately at the moment there are both “parser” and “parsing” tags, and various packages use one or both — plus AFAICT searching for multiple tags is a logical AND not OR of those tags. So you need to do both: - https://pkgd.racket-lang.org/pkgn/search?tags=parser - https://pkgd.racket-lang.org/pkgn/search?tags=parsing to get all. :disappointed:

It would be great to pick just one — maybe the noun, “parser” — and update those couple dozen packages’ tags.

And/or (no pun intended) maybe the pkg search could allow tags to be AND/OR.

Is the package owner the only one who can update tags? I remember wanting to do a tag cleanup some time ago and being blocked on the catalog not having a way to grant “tag admin” powers to people

Q about the package server—is there a way to mark “versions”?

We distribute Herbie through the Racket package manager (in preparation for plugins, dependencies, and so on) and I’d like there to be a way to get the 1.3 version exactly, instead of whatever we have in master

You can specify a tag or commit in the url

In which URL?


I know it’s not the “Version Exceptions” box—I made that mistake earlier

The source url. Go to “Edit this package” and look for “Branch or commit”

Oh, I see what you mean. Is there a way to list multiple versions?

version exceptions, that’s it

Got it. So whenever I release a new version I’ll update the URL

But there isn’t a way to download old versions

ok

right, no old versions through raco pkg
(unless you happen to be using an older racket that matches a version exception)

I think the recommended work-around is to clone the package & use git checkout

yeah, makes sense

Users can choose to download earlier versions by manually using the URL with the commit or release tag/branch in it instead of the package name, without using the package server at all. You shouldn’t have to clone and git checkout. So if someone wanted the old v1.0 of herbie instead of v1.3, then instead of raco pkg install herbie
, they would use raco pkg install <https://github.com/uwplse/herbie.git?path=src#v1.0>
Edit: for it to cooperate with deps
declarations, they should include the name herbie
as well raco pkg install --name herbie <https://github.com/uwplse/herbie.git?path=src#v1.0>

Oh huh, cool, I didn’t know you could do that

Another Q about the package server

I have two tests failing on the package server. One is because the package server doesn’t include the bench
directory, which is outside the package; the other is because that test takes ~10min to run, and the package server times out after 60s.

Is there a way I can disable tests just on the package server, but that wouldn’t also affect raco test
normally?

@pavpanchekha see https://github.com/emina/rosette/issues/17#issuecomment-209621055

Got it, thanks

Rosette does (define test-omit-paths (if (getenv "PLT_PKG_BUILD_SERVICE") 'all '()))

in the package info.rkt

Thanks, I’ll do something similar

No, I don’t think that information is kept by ffi/unsafe
. If you’re interested to know for debugging purpose which library was found, search info is logged to ffi-lib
at the debug level.

Hm… maybe it only logs the search attempts on failure.

FWIW, I had this same question a few days ago. Thanks for asking it!

I guess ffi-lib
bottoms out by passing the raw library name (without a path)_ to the system. So maybe you want logging at the OS level… See man dyld
for a list of environment variables that you can to set to get information.

Thanks @jerome.martin.dev - added

@greg I’ve added the links, rather than replacing the existing ones.

I noticed that Racket isn’t one of the languages available on Travis CI. Has anyone discussed adding Racket support as a community maintained addition?


That should pretty easy to incorporate into Travis’ existing infrastructure I think

I mean like upstream it

There’s been some discussion, but since Travis was acquired some months ago I don’t think they’re likely to be putting effort into new features or expanded language support.

It’s probably more maintainable anyway to use a Docker-based CI service

Actually they’re putting more effort into both! I was at a conference last week at which Travis had a big presence and I’ve been talking with them a bunch. They’re rolling out support for ARM builds, and they may even revisit adding FreeBSD. They said that being acquired gave them more resources to focus on those things.

There are a number of PRs, including by Travis employees, adding new language support

I think most Travis Linux builds are running on Docker

They’re running on docker but they don’t let users specify custom docker images to run their tests in. Circle CI does that for example.

Oh that’s good to hear!

Oh, I see what you mean

Yeah that is nice

Yeah, some of my colleagues were similarly speculating that their open source offerings would decline after being acquired, so I was really happy to hear that they’re expanding.

@ararslan https://docs.travis-ci.com/user/languages/community-supported-languages/ doesn’t sound particularly easy, to me. Especially compared to the status quo. What I hear is: Do things in Ruby. Talk with Travis about how they’d prefer to support version matrices, that’s not documented there and in any case not how it already works fine now. Still be on the hook to do “support” — but with two other people, and within Travis’ system which if it turns out to be JIRA please put a pencil in my eyeball. :smile: ¯_(ツ)_/¯

But if some other folks think it would be worthwhile, I’d be happy to hand over the reins for the next 6 years.

I’m one of the maintainers of the Julia language integration for Travis, which is community supported. As far as I can tell, all you really need is a simple Ruby script in the travis-build repo. The Ruby script generates a Bash script that runs in the image that does the build.

@greg I’m willing to be one of the two other people

@notjack Sounds good. When you find the other two people, and it goes live on Travis, let me know and I’ll update the README to point people there. Until/unless that happens, I’m glad to keep maintaining the existing thing.

Today, one of mflatt’s commits (https://github.com/racket/racket/commit/ec5b45e4f80341911524eebe478d70e5e60465fa) taught me that when writing macro-generating macros you can use ...
to escape ...
in an entire expression. So you can write this: (define-syntax-rule (define-maker-definer definer-id maker)
(...
(define-syntax-rule (definer-id id ...)
(begin (define id (maker)) ...)))
Instead of this: (define-syntax-rule (define-maker-definer definer-id maker)
(define-syntax-rule (definer-id id (... ...))
(begin (define id (maker)) (... ...))))