today was a good and rackety day for me
@mflatt @popa.bogdanp somehow the setup-racket download failed for a snapshot, see https://github.com/racket/typed-racket/runs/1011276492#step:3:1\|https://github.com/racket/typed-racket/runs/1011276492#step:3:1. I upgraded it to v10 so that may fix things but I didn’t expect anything to fail
That’s because of the recent changes to the Utah snapshots server. I updated the URL handling code in 0.10 so upgrading should fix the problem.
https://github.com/Bogdanp/setup-racket/pull/12 and https://groups.google.com/g/racket-users/c/k_o3Ug-lK_s/m/HwhCtbC6BQAJ
Right, that’s what I expected, but I also had thought that the plan was not breaking anything.
Ah, I see. Since the URL-generating code is bundled into each version of the GH action, I don’t think there’s much I can do to handle these kinds of changes on my end. Going back and updating existing tags doesn’t seem right.
I suppose I could recommend that repos pin the action @master instead of a specific tag. That way they’ll get these kinds of changes transparently.
No, I don’t think you need to do anything more than what you did
@mflatt: how do I test demo-manual.scrbl? I ran scribble demo-manual.scrbl and the first few lines of the output is:
[Output to demo-manual.html]
Warning: some cross references may be broken due to undefined tags:
(dep ((lib "racket/base.rkt") for-label))
(dep ((lib "racket/base.rkt") define))
(dep ((lib "scribble/private/manual-form.rkt") specsubform))
(mod-path "racket/base")
(dep ((lib "racket/private/pre-base.rkt") for-label))
(dep ((lib "racket/private/pre-base.rkt") define)) which indicates that I’m invoking it wrong. These tags should be defined since I didn’t touch any of them at all.
This is a job for raco setup, but you can use raco setup -l scribblings/scribble.
@sspillane has joined the channel
is there something that automates sending pull requests to update version-pinned users of your action when you release a new version? I’ve had this problem with https://github.com/jackfirth/racket-package-ci-action\|https://github.com/jackfirth/racket-package-ci-action too
I have updated the plot package to allow specifying picts for the plot titles and axis labels (this is similar to my previous change which allowed picts to be used as legend entries). This will allow using arbitrary images instead of just text — this was done because there were at least two requests of using LaTeX notation as the labels, and this can now be done using the latex-pict package. Here is the pull request, if anyone wants to have a look and provide feedback. I will leave it open for about a week before merging it: https://github.com/racket/plot/pull/65
I would really like to see the Racket mailing lists move off Google Groups. They’ve steadily gotten harder for me to use (I don’t have a GMail account and try to avoid signing into Google whenever I can).
It’s at the point where I don’t bother to respond to something I could respond to unless it’s really compelling. Now maybe that’s the way it should be but right now it’s kind of an artificial barrier.
@yuyang990421 has joined the channel
@plragde What works well for you in other contexts that you think may be a good replacement for GG?
When creating macros, is syntax-parse preferred to syntax-case? And if so, should the documentation reflect this?
I’ve seen a number of people claim that using _syntax-parse_ is strongly preferred over the older _syntax-case_ approach. It’s a much more robust, strongly-typed approach, with a richer pattern language. But in both the <https://docs.racket-lang.org/guide/macros.html?q=syntax-parse|Racket Guide> and the <https://docs.racket-lang.org/reference/Macros.html?q=syntax-parse|Racket Reference>, the Macro chapters focus exclusively on _syntax-case_ – I’m not sure if the existence of _syntax-parse_ is even mentioned. I didn’t even realize that _syntax-parse_ existed until I stumbled across blog postings and other content outside the official Racket site.
I ended up finding this <https://docs.racket-lang.org/syntax/index.html?q=syntax-parse|set of documentation>, which seems to be the main hub for information about _syntax-parse_ and related functionality.
Should I focus on learning syntax-parse instead? Or learn the two approaches to macros in parallel? After all, even if it’s true that using _syntax-parse_ is better, there’s a huge amount of existing code out there using _syntax-case_, so I’ll want to understand syntax-case as well.
I’m confused — does it not just function as a mailing list for you?