Hi all, I have been playing with some regexp, and it seems really easy to break the REPL with some faulty regex constructions. I tried to create a regular expression that would match an html filename as shown, and I get the following output: > (regexp-match? #px".*\.html?$" "sy.html") ; ::128: read-syntax: unknown escape sequence `\.` in string ; Context: ; /usr/share/racket/collects/racket/repl.rkt:11:26 ; html?$: undefined; ; cannot reference an identifier before its definition ; in module: top-level ; Context: ; /usr/share/racket/collects/racket/repl.rkt:11:26 " " ; sy.html: undefined; ; cannot reference an identifier before its definition ; in module: top-level ; Context: ; /usr/share/racket/collects/racket/repl.rkt:11:26 Anything I type after that in the REPL does not get evaluated unless I put two quotes like so: > (+ 2 3) " " ")\n(+ 2 3)\n" The examples in the documentation seem to work fine for me. In fact I can replicate this behaviour only when I construct invalid #rx strings, like #px"oops_forgot_to_escape\b"

So in short, (1) how do I match an html filename? (2) how do I deal with the repl acting up like that? Restarting the REPL for every failed construction is mildly disruptive for me.

@raykar.ath DrRacket or racket-mode in Emacs?

I am using racket-mode on emacs, but otherwise had the same issue while running the REPL on my terminal.

The problem is to match a literal dot? I think the pattern is [.]

For the repl getting confused - maybe @greg has a tip?

Or \\.

The problem is that #px"..." is still a kind of string quote, so there are limited number of characters that can follow \ (e.g., \\, \n, \r). So you need to encode things twice. Once for string quote. Another for regex.

DrRacket seems to handle the repl acting up weird problem, btw.

So I consider this to be REPL’s fault.

I (re)tried raco setup metapict to check, but that doesn’t solve the problem.

The metapict manual has become so large, that I prefer to scribble a single section( such as curve.scrbl) at a time.

The MetaPict documentation has been updated on the documentation server.

Still looking for fix for the red underlining of join, curve: and friends. https://docs.racket-lang.org/metapict/index.html?q=metapict#%28def._%28%28lib._metapict%2Fcurve..rkt%29._join%29%29

https://github.com/soegaard/metapict/blob/master/metapict/scribblings/curve.scrbl

Observation:

With @(require (for-label metapict (except-in racket angle box open path? unit identity ...)) the curve: constructor is rendered correctly.

With @(require (for-label metapict (except-in racket angle box open path? unit identity ...)) (for-label metapict/structs)) it becomes red again.

Not sure why.

And there is no effect on join.

Thanks, @sorawee. That was the culprit. Although the repl definitely should handle these more gracefully. I suppose this is a bug?

Yeah, I would consider it to be a bug

It looks like the problem is that the REPL doesn’t consume the entire line at once, but only read things from the input port as necessary

This means that once the error occurs, it errors out immediately while leaving the rest of the input port intact

And then continue to process it

Turns out this was brought up before here: https://github.com/racket/racket/issues/448 I am convinced this is technically not a bug, because the repl should suspend on encountering a , but this behaviour could be improved in some way to avoid being stumped like I was.

I mean, yeah, not a bug per se, but it definitely should be improved.

Under certain definitions, that’s considered a bug :stuck_out_tongue:

A somewhat related issue is https://github.com/racket/racket/issues/2432

I can confirm the problem

Thanks for trying it out.

So the bottom line is that if you require for-label already from one place, doing it from another place will screw up the link

Just tried it on defproc and it’s the same problem

How often is the documentation rebuilt for packages? Is it possible to trigger a doc-rebuild for a particular package?

;; test.rkt #lang racket/base (provide a) (define (a) 1) ;; main.rkt #lang racket/base (require "test.rkt") (provide a) ;; test.scrbl @require[@for-label[pkg-name pkg-name/test racket/base]] @defmodule[pkg-name] @defproc[(a) any]{foo}

is the minimal example that demonstrates the problem

Maybe the problem isn’t in curve.scrbl then. Maybe I have require for-label twice in another scrbl-file.

@samth said that there’s a machine that continuously runs package rebuilt, but I found the machine dying a few times

The docs for quickscript haven’t been updated for a few days already

Could the reason be that join and friends are defined “structs.rkt” and not in “curve.rkt”. (I have a defmodule[metapict/curve] at the beginning)

I checked - but the other files has reasonable looking for-label requires.

Well, you did provide all-from-out "structs.rkt" in the top-level file

So (for-label metapict (except-in .....)) will provide curve:

Yes.

and (for-label metapict/structs) will also provide curve: again

which cause the problem

Yes.

The odd thing is that removing  (for-label metapict/structs) fixes curve: but not join, .., — etc.

Ooh! Turns out I have an (provide (struct-out curve:)) in curve.rkt.

So providing join, .. etc from curve.rkt too might fix the problem.

Providing join from “curve.rkt” did help.

So the defmodule declaration has an effect on that section.

Thanks for the help.

Your case seems to be different

quad : 125 #<datetime 2020-07-07T02:55:49> #<datetime 2020-07-07T02:57:15> fpbench : 55 #<datetime 2020-07-06T23:58:04> #<datetime 2020-07-06T23:58:42> tessellation : 37 #<datetime 2020-07-06T22:35:09> #<datetime 2020-07-06T22:35:36> racket-build-guide : 26 #<datetime 2020-07-06T22:34:34> #<datetime 2020-07-06T22:34:54> plt-services : 6 #<datetime 2020-07-06T22:34:20> #<datetime 2020-07-06T22:34:29> mind-map : 33 #<datetime 2020-07-06T22:33:38> #<datetime 2020-07-06T22:34:02> racket-graphviz : 47 #<datetime 2020-07-06T22:32:41> #<datetime 2020-07-06T22:33:13> metapict : 268 #<datetime 2020-07-06T22:28:01> #<datetime 2020-07-06T22:29:32> expander : 21 #<datetime 2020-07-06T22:27:35> #f cs-bootstrap : 19 #<datetime 2020-07-06T22:26:42> #<datetime 2020-07-06T22:27:01> lambda-sh : 252 #<datetime 2020-07-06T20:57:00> #f digimon : 162 #<datetime 2020-07-06T20:49:54> #<datetime 2020-07-06T20:52:23> sfont : 70 #<datetime 2020-07-06T11:14:42> #<datetime 2020-07-06T11:15:22> russian-lang : 7 #<datetime 2020-07-06T05:37:41> #f quickscript-test : 43 #<datetime 2020-07-05T20:38:59> #<datetime 2020-07-05T20:39:31>

It looks like the build server is doing fine

It even picked up your change to quickscript-test which iiuc is after your change to quickscript

So it maybe be because quickscript is bundled, and the docs are kept in sync withe the current (non-nightly) version?

is this output visible somewhere, or did you parse it yourself?

bundled?

with drracket, as a dependency

my sentences are a little too

Ah, that is certainly a possibility

I parse it myself

@laurent.orseau: see https://www.cs.utah.edu/plt/snapshots/current/doc/quickscript/index.html

Yes, the pkg-build server doesn’t rebuild things that are in main-distribution. That’s one of the drawbacks of having a lot of libraries in main-distribution — they only get updated every few months for people using releases.

Right. Related: updating one such package can be cumbersome because it’s likely installed in installation scope (may require sudo to update).

Is it possible to replace/subsume a package installed with installation scope with the same package installed with user scope? That could be by default

So if I do raco pkg update plot it’s going to install a user scope package plot with the latest version, deactivating the installation-scope one.

This also explains why quickscript-test (not in the main dist) fails: it is applied to an old version of quickscript.

quickscript-test should probably be in main-distribution-test then

what if you do raco pkg update -u plot?

probably. It wasn’t ready last time though

“package installed in a different scope”

Would the new package manager that people have been talking about last month help?

Like, the main distribution would lock a version

But the development version could be updated freely

there’s not really anything required for being a dependency of main-distribution-test. You should make a PR adding quickscript-test

@sorawee I don’t think anyone was talking seriously about building a totally different package manager, but about improving raco pkg (or maybe they were, but I haven’t seen anyone do anything in that direction). And I don’t think there’s a problem here — you can certainly update to the development version of quickscript with a single command.

@michaelmmacleod is building an experimental one: https://github.com/MichaelMMacLeod/rpkg

Seems interesting.

@jbclements Whenever I try to install portaudio now, I get this error:

raco pkg update: cannot find package on catalogs package: portaudio-x86_64-linux

oops, just typed defile instead of define

#quickscript-competition

Is there a nice/standard way to escape out of macro expansion up to the module context level and specify a replacement expansion. For a simple example, a macro void-this-expression to turn (m (void-this-expression)) into #'(#%plain-app void), where m is a macro we also control. The fuller situation is that I have a language where every form is custom (including #%app etc) and want a mode where syntax errors can be less-than-fatal. If it helps, we can restrict to cases with no local definition contexts. Everything could local-expand, but that seems like starting to write my own expander — is this kind of thing where one starts taking over #%module-begin and walking the ast oneself, rather than working within the current model of macros?

I think the easiest answer is for m to recognize void-this-expression. But probably using local-expand is going to be needed.

Thanks for the confirmation.