How to debug colorer for #lang? All the feedback I get is the #lang line turns red

One advice:

; REMEMBER to restart DrRacket to test any changes in the ; color-lexer. The lexer is only imported into DrRacket ; at startup. found in

https://github.com/soegaard/minipascal/blob/master/minipascal/mini-pascal-lexer.rkt

If I run (system “sudo whoami”) in DrRacket, I get an error because a terminal is required to read the password for sudo. Is there a simple way to make the DrRacket REPL so that it will ask me for the password? If not, perhaps I need to create run a terminal like xterm, and run the command in that?

@rp Check man sudo to see if there is a suitable option available. On macOS I see one can do: -A, --askpass Normally, if sudo requires a password, it will read it from the user's terminal. If the -A (askpass) option is specified, a (possibly graphical) helper program is executed to read the user's password and output the password to the standard output. If the SUDO_ASKPASS environment variable is set, it specifies the path to the helper program. Otherwise, if sudo.conf(5) contains a line specifying the askpass program, that value will be used. For example: # Path to askpass helper program Path askpass /usr/X11R6/bin/ssh-askpass If no askpass program is available, sudo will exit with an error.

Or perhaps: -S, --stdin Write the prompt to the standard error and read the password from the standard input instead of using the terminal device.

But, maybe it is easier if you do: sudo racket your-program.rkt instead of asking for a password later?

OK, that’s great. I guess trying to turn the REPL into a “proper” tty is the wrong way to tackle this problem. I’ll have a look into the other options like you suggest.

Thanks for the suggestions - I appreciate your help.

Also, it’s better practice to let the user type sudo themselves, which asks for the password straight away, so that they know they’re not entering their password in a random program

Laurent, that’s a good point, thanks.

Are prefab structures considered unreadable? In the past I’ve serialized them without issue, but put-preferences is complaining: “printf: printing disabled for unreadable value” EDIT: to be clear, in this case I’m not using serialize, I’m just passing a list of structs to put-preferences. I could serialize them first if that is the norm for putting structs in preferences files.

Re-reading the docs I think it is clear that prefab structs aren’t readable and I do need to serialize them first before sending to put-preferences. Is that the best approach? If there is a convention for storing data in preferences files I’d like to stick to it. Would it be better to provide a prop:cust-write function for my structs?

Prefab structs are definitely readable

Prefab structs are readable (and writable). See https://docs.racket-lang.org/reference/structures.html#(tech._prefab), "…can be parsed and written…". But it looks like print-unreadable (wrongly, I think) disables writing prefab struct instances, and put-preferences sets print-unreadable to #f to protect the preferences file. That looks like a bug to me.

Interesting! That is the way that I hoped it would work before I wrote the code. I have it working with serialize/deserialize for now but if it is indeed a bug, it would be nice not to have to do that.

I just filed a <https://github.com/racket/racket/issues/3827|bug report>. I don’t know of a workaround better than using serialize, unfortunately.

Thank you! Serializing will be fine for me until this is fixed.,

I want a function that returns a function that returns consecutive integers when called repeatedly. Here’s one possibility: (define (sequence-generator) (define count 0) (lambda () (set! count (add1 count)) count)) > (define a-generator (sequence-generator)) > (a-generator) 1 > (a-generator) 2 > (a-generator) 3 I had read about streams and thought that in-naturals would be a natural :wink: way to provide such an infinite integer sequence. But then I also noticed that if I create a stream with (in-naturals) and call (stream-first ...) on that, I always get the same number. Now I’m sure it’s supposed to work that way, but I also wonder if there’s a way to do with in-naturals in a simpler way than I’m using in my closure function above.

In other words, is there a pattern using streams to get a sequence of values on repeated calls, similar to how generators work in Python: >>> sequence_generator = iter(range(1, 1000)) >>> next(sequence_generator) 1 >>> next(sequence_generator) 2 >>> next(sequence_generator) 3 (I know that this range call doesn’t give an infinite sequence; this code is just for illustration.)

I believe you can use (sequence->generator _s_) to turn (in-naturals) into a generator.

Yep, that works. Thanks! > (require racket/generator) > (define (sequence-generator) (sequence->generator (in-naturals))) > (define my-generator (sequence-generator)) > (my-generator) 0 > (my-generator) 1 > (my-generator) 2 > (my-generator) 3 I thought that streams were already so similar to Python generators that I didn’t think of the possibility that there might be yet another concept/library for that. :slightly_smiling_face:

In the end I needed something slightly more complicated, but a generator helped here as well: (define (make-node-id-generator) (generator () (for ([i (in-naturals 1)]) (yield (format "n~a" i)))))

Otoh, if the whole program does not need sudo privileges, it should not have them…

Won’t work if the prefab struct is mutable though, for some reason

I have run into a problem. Can you spot the solution? #lang racket (require (for-syntax syntax/parse racket/syntax)) (define-syntax (cache stx) (syntax-parse stx [(_cache e:expr) (with-syntax ([cached (format-id stx "cached")]) (syntax-local-lift-module-end-declaration (syntax/loc stx (define cached #f))) (syntax/loc stx (cond [cached cached] [else (set! cached e) cached])))])) (define (foo) (cache (random 42))) (foo) (foo) I get the error “cached: unbound identifier in: cached”.

I tried the macro stepper with two things to see when the lift forms are introduce: 1. Place (cache (random 42)) at module-level instead of inside (foo). 2. Expands to something like (identifier-binding #'cached)

As I see the results suggest that (1) the lifted forms are introduced after all module-level forms are partially expanded (2) Lifted forms cannot introduce new module-level bindings once the partial expansion is finished

So (cache ...) inside (foo) cannot introduce a new module-level definition

The expander guarantees (2) by imposing this behavior upon syntax-local-lift-module-end-declaration: > If the current expression being transformed is in <https://docs.racket-lang.org/reference/syntax-model.html?q=syntax-local-lift-module-end-declaration#%28tech._phase.level%29|phase level> 0 and not in the module top-level, then _stx is eventually expanded in an expression context.

Use syntax-local-lift-expression instead. You don’t get to control the variable name; the macro expander generates one for you that won’t cause problems for the rest of the module.

When setting up a config.rktd file with a config-tethered-console-bin-dir, what is the right thing to put for bin-dir? (I am trying to chain to an existing installation as a wider scope, as in <https://groups.google.com/g/racket-dev/c/dHAFwzlFwNA/m/xfVGxIYaAgAJ|this message>.)

I’m not sure I remember how this is supposed to work, but I think the idea is that a “config.rktd” in the addon space would have just the tethered entries and not others.

In case another reference helps. the relevant commit was 6369e567097866d6a65a3da32c8125131fabdd73.

No, I’m pretty sure I don’t remember how this was supposed to work.

Maybe it’s that that “config.rktd” for a sandbox area is supposed to point at all the directories that the installation would point to, plus the directories for tethered binaries. So, you’d set bin-dir to whatever the next layer’s “config.rktd” says or whatever it would default to.

On Nth thought, that doesn’t sound right either. Maybe it should be just some other directory that you don’t really use, because you’ll want to use the tethered ones.

Specifically, I ran this command: /gnu/store/7vy0ikhd3ws5v6jydzx7aipvs4jv7rb9-racket-minimal-8.1/bin/racket \ --config /home/philip/code/tmp/racket-config-tethered/etc/racket/ \ -l raco -- setup --no-user

ah. as it turns out, my get-info didn’t have the right signature. I was copying it from a #lang that used syntax/module-reader, which must do some automatic wrapping

Has there been any changes to racket’s ffi between 8.0 and 8.1 cs? I have some programs that use the ffi that stopped working. They are rather complicated so I came up with an example using the pict3d library.

#lang racket/base (require pict3d) (pict3d->bitmap (sphere origin 1/2)) Error message: gl-create-program: ERROR: Compiled vertex shader was corrupt. ERROR: Compiled geometry shader was corrupt. ERROR: Compiled fragment shader was corrupt. context...: /Users/ayman/Library/Racket/8.1/pkgs/pict3d/pict3d/private/memo.rkt:83:2 /Users/ayman/Library/Racket/8.1/pkgs/pict3d/pict3d/private/engine/draw/draw-pass.rkt:310:0: send-draw-params /Users/ayman/Library/Racket/8.1/pkgs/pict3d/pict3d/private/engine/draw/draw-pass.rkt:364:4: draw-opaque-material-pass /Users/ayman/Library/Racket/8.1/pkgs/pict3d/pict3d/private/engine/draw/draw-passes.rkt:429:0: draw-draw-passes* /Users/ayman/Library/Racket/8.1/pkgs/pict3d/pict3d/private/gui/typed-pict3d-bitmap.rkt:11:0: pict3d-set-bytes! .../gl/context.rkt:20:24 /Users/ayman/Library/Racket/8.1/pkgs/pict3d/pict3d/private/gui/untyped-pict3d-bitmap.rkt:42:0: pict3d->bitmap /Applications/Racket v8.1/collects/racket/contract/private/arrow-val-first.rkt:489:18 body of "/Users/ayman/git/github.com/aymanosman/concept/Untitled.rkt" Not sure where to post this? Should it go in racket/racket Github repo issues?

also, re: this, there’s a “Reload #lang extensions” button under the “Racket” submenu which will let you see the changes to lexer w/o restart

I see that after today’s changes, the error is foreign-call: cannot pass non-atomic pointer to a function pointer: #<cpointer> function: 'glShaderSource context...: There have been corrections to the FFI realted to _cast that could potentially change something from seeming to work (as long as you’re lucky about GC timings) to a crash in 8.1 to this error in Git HEAD.

Or it could be a different kind of bug introduced in v8.1.

I’ll investigate more.

The crash seems in the vicinity of glShaderSource, which takes an array of strings — so, I think my initial guess may be right.

In v8.0, an array to hold bytes strings in CS was allocated as atomic memory. That’s wrong, because the byte-string references don’t get moved if a GC happened.

In v8.1, the array is corrected allocated as non-atomic. But, then, passing non-atomic memory to C just isn’t right, hence the crash.

And HEAD restores the error message that was supposed to catch problems passing non-atomic memory for C functions.

OK. I’m working with my own bindings to opengl, so any pointers to how I can fix those would be helpful, thanks.

Maybe I can run HEAD to test the fix. I’ve never done that before, I assume I just follow the build instructions.

In HEAD, (_vector i _string*/utf-8) can be replaced by _vector-of-string*/utf-8 defined as (require ffi/unsafe/string-list) (define _vector-of-string*/utf-8 (make-ctype _string-list/utf-8 vector->list list->vector)) As it happens, ffi/unsafe/string-list is new just today.

Cheers :)

I can imagine changing _vector and _list to treat _string*/utf-8 and related element type specially, but I’m not sure that hiding the general issue like that is a good idea.

https://github.com/jeapostrophe/pict3d/issues/25

Using the approach you showed above worked (using _string-list/utf-8). I see from your Github issue comments that you are going to explore some other options, so I’ll wait to hear about that. Cheers.