
I somehow found myself in a spot where (syntax-local-value id)
returns a value (specifically, 'foo
) but (syntax-local-value/immediate id)
raises syntax-local-value/immediate: not defined as syntax
. That seems like something that should never happen, did I find a bug?

@notjack That sounds like a bug to me.

What’s the convention that most use for unused arguments. For example, I am calling (split-path ...)
that returns three values but I am only interested in the second so I tend to go (define-values (_1 name _2) (split-path ...))
. Any better way to do this?

s/arguments/values

You can use match-define
from racket/match
and use _
to avoid certain bindings.

@notjack I agree - that sounds like a bug

@lexi.lambda ah, so something like (match-define-values (_ name _) (split-path ...))
Thanks!

I cannot seem to find anything from find-system-path
but I was expecting to have a way to grab the full path of the current racket
executable. Imagine I have a stable racket in path, say 6.12, but I am running HEAD and want the path to this racket instead of the stable one… How can I get it?

I think that’s what 'exec-file
gives you from find-system-path
.

If you combine that with (find-system-path 'orig-dir)
in the case that the path is relative, you should be able to get the full path.

ah… should’ve tried. I was convinced 'exec-file
would give me the path to the current script. i.e. racket foo.rkt
when calling (find-system-path 'exec-file)
would return .../foo.rkt

@pocmatos I recommend find-exe
from compiler/find-exe

@mflatt thanks, works great.

Does the search box at "http://pkgs.racket-lang.org\|pkgs.racket-lang.org" work for others? When I try, it seems to get stuck on a request to the server.

also signing in doesn’t seem to work

which is the same server

This problem seems to happen a lot

yes

@jeapostrophe Is there something we can work on to make the server more reliable?

@mflatt you’re not the only one…

Whoa, Racket just seg-faulted on me for the first time: Welcome to Racket v6.12.
> (syntax->datum
(parameterize ([current-namespace (make-empty-namespace)])
(expand-syntax #'(module m racket/base (+ a 3)))))
SIGSEGV MAPERR si_code 1 fault on addr 0x18
Aborted (core dumped)

Is it just me?

@lexi.lambda @samth @mflatt Tony’s version has a single-threaded nature and there’s an unprotected read, when it fails because a client disconnects too early, it crashes that thread and it can’t take anymore. I’ve tried many times to locate it and fix it but I’ve never found it. The backtrace is useless.

Every few weeks I try again

cc @tonyg

@dedbox same here can’t get anymore reproducible. :slightly_smiling_face:

@mflatt ^^^^

@dedbox I see the crash, too, in v6.12. It doesn’t crash in the current development version – where the macro expander has been completely replaced, so it’s not surprising that this got fixed along the way.

ok thanks!

Okay, someone please tell me I’m not hallucinating: is quote-syntax
really not in (kernel-form-identifier-list)
from syntax/kerncase
? It should be, right? How has this never been noticed before??

quote-syntax
really does seem to be missing. Probably no one noticed because almost all uses are with local-expand
, which would quietly add quote-syntax
itself

#%plain-module-begin
is also missing. Can I safely push a change that adds both of those? Does that change need a @history
annotation?

Yes, and I think a history
annotation is worthwhile

@mflatt Is there a reason the scope attached by syntax-local-lift-require
should be treated as a macro-introduction scope for the purpose of syntax-original?
-ness? It looks like Racket 6 had the same behavior, but I don’t think it really makes sense.

If anything, the scope seems more similar to an intdef scope than to a macro-introduction scope to me.

@lexi.lambda A lifted require
seems non-original to me, but I wouldn’t object to an optional argument to control whether the created scope is a macro-introduction scope

The require itself is non-original, but it shouldn’t make the whole form it brings bindings into scope for non-original, no?

Ok, I see that point. I don’t know whether changing it would cause any problems, but probably not.