Does Racket currently use nanopass framework to compile itself?

Nanopass is used to build Chez Scheme.

Does that mean Racket-CS uses the nanopass framework to compile because it is built on Chez? (I think it does - but I’ve been wrong before)

As far as I know the Racket-toChez compiler doesn’t use Nanopass. But the compiler from Chez Scheme to machine code is built with Nanopass.

I didn’t think of that.

Does that mean when we compile Racket CS to machine code we have Racket [-no-nanopass->] ChezScheme [-nanopass->] machine code? i.e. only the last part uses nanopass framework and ‘transpiling’ Racket to Chez uses a single pass through a separate compiler?

I could be wrong, but yes to the first question. I don’t think “the transpiling” is done in a single pass though.

But I don’t know.

This is probably in the documentation. I should look. (I will later)

There are multiple passes even in the Racket -> Chez Scheme step, but that’s basically right.

Is there a doc that says what each pass does in both worlds?

No, there’s just the implementations right now.

Does anyone understand why this program immediately consumes all of the cpu while avoiding peeking-input-port (i.e. reading from in) does not? #lang racket (define-values (in out) (make-pipe)) (fprintf out ".") (let ((i (peeking-input-port in))) (displayln (read-line i)))

I don’t know for sure but I would suspect trying to display the result of read line creates an infinite loop.

Does it help to change the buffer mode?

I see the same behavior if I set it to ’block or ’none

From a quick look, it seems to be a problem with peeking-input-port.

Specifically, peeking-input-port uses the pipe as an event when it can’t peek more past the first byte, but the pipe is ready as an event since there’s a byte ready.

Thanks, should I file an issue?

No need

Sorry if this has already been asked & answered but why is https://download.racket-lang.org/releases/7.9/catalog/ throwing 404?

I get stuff like &gt; raco pkg migrate 7.7 Packages to install: racket-langserver rackjure retry 00: Resolving "racket-langserver" via <https://download.racket-lang.org/releases/7.9/catalog/> 01: Resolving "rackjure" via <https://download.racket-lang.org/releases/7.9/catalog/> raco pkg migrate: cannot find package on catalogs package: racket-langserver raco pkg migrate: cannot find package on catalogs package: racket-langserver

is that expected?

@daniel.kvasnicka.jr there are two issues here. One is that the initial release of 7.9 had a problem in the configuration; that has been fixed if you download what’s on the website (it was fixed a couple weeks ago). Second is that the URL you posted doesn’t serve any content; that is not a problem; see for example https://download.racket-lang.org/releases/7.9/catalog/pkgs which returns the correct data.

Ah, so this seems to be a Manjaro Linux package issue then. Thanks @samth for the info!

They likely need to update.

Will breaks generated from the OS only be received by the main thread (or a nested thread of the main thread?)

Yes

I have a package that uses ffi-lib to load some libraries.

What’s the best way to allow the user to change the path of the libraries loaded?

Is there an example / library somewhere I can look at?

At first I thought - just use a parameter - but that’s not going to be enough. https://github.com/soegaard/sci/blob/master/flomat/flomat.rkt#L72

define-ffi is syntax, so a parameter won’t do. A simple option is an environment variable, but of course this requires to re-setup the library if the variable changes, and raco may not see the need to recompile since the files haven’t change. So this can be problematic (best way to solve this: delete all compiled directories of the collection).

Is there a reason not to rely on OS-level environment variables like LD_LIBRARY_PATH?

I suppose an environment variable could work. The tricky part about BLAS and LAPACK is that there are several versions around. Some use OpenBLAS and others use what Intel provides. So a user might want to see which of the different versions that work best on his machine.

I can’t think of a better way than using an environment variable, so I’ll try that. It would be simpler to the explain the setup without though.

Is LD_LIBRARY_PATH also used on Windows?

I had a Windows user that installed libopenblas.dll in “c:/users/username/projects/blas/bin/libopenblas.dll” but that does not seem like a standard installation folder.

Awesome, that will simplify what I’m working on a lot.

Windows looks for DLLs in PATH instead of LD_LIBRARY_PATH.

Okay - that sounds simple enough - the user simply needs to add his installation folder to PATH then.

Thanks.

yikes https://gist.github.com/jackfirth/c4d66bd7378aa3ef4e9576eda0c094a9

That eq? produces #f I hope

it does not

(refresh the gist, I added comments)

Why is it a problem that eq? produces #t?

Also on Racket CS , the last two immutable? calls produce #f, I suspect unsafe-string->immutable-string! makes a copy since: (immutable? (unsafe-string->immutable-string! s1)) produces #t, but running (immutable? s1) after that produces #f

because it means different calls to (string-append) return values that all share observable mutable state with each other

unsafe-string->immutable-string! says it “potentially” destroys the string its given and reuses its space, I think it will just sometimes produce #true for the second-to-last immutable? check and sometimes it won’t, subject to implementation whims. But it’s extremely weird that the last immutable? check could ever return #true.

> because it means different calls to (string-append) return values that all share observable mutable state with each other Using string-append with any other string, including passing the same (as in eq? same) string will produce different non-eq? results. It seems that only the empty strings are eq?

In presence of potentially destructive operations, objects should not be shared. I agree that (eq? s1 s2) should be #f.

Yeah it’s not exploitable in this case because you can’t change the length of a string, but it’s still very weird and not good

On 7.8 [3m] I don’t see the same behavior. Is this 7.9 and/or CS?

I’m also guessing this is likely due to string-append having a default return value that’s a literal in it as opposed to returning a new string each time.

The real question is, after you change the string, will a subsequent call to (string-append) return the same, altered string?

At the end of the day, it’s really just: (eq? (string-append) (string-append)) ;=> #t I think it’s debatable whether this is bad or not. If they are immutable (7.8 [3m] says yes), then there’s no real harm.

If, however - even with “unsafe” code - it’s possible to modify the literal such that later calls to (append-string) end up returning the modified string, I’d consider that pretty bad.

Regardless, that’s probably up near the top of my list for “best titled gists” :slightly_smiling_face:

Literal strings are immutable, not mutable, so I honestly am pretty confused how this behavior came about

and I definitely think (eq? (string-append) (string-append))should be true if and only if (string-append) always returns an immutable string

bug?