Hopefully quick question: in scribble, if I want to write @racketblock[(cons (circle 30 "solid" "red") '())], it’ll typeset all that text just fine. How do I anti-quote the call to circle so that it evaluates to a picture, and I get typeset output of (cons <the actual circle> '())?

@blerner #,

perfect, thanks :slightly_smiling_face:

(might be nice to mention that in https://docs.racket-lang.org/scribble/reader.html...)

Well, it’s a racketblock escape, not an at-reader escape

mmm, fair. and it is indeed mentioned in racketblock, so I sit corrected :slightly_smiling_face:

Is calling callback-proc in atomic mode (in the following snippet) safe?:

(define ffmpeg-log-list '())
(struct ffmpeg-msg (name
                    level
                    msg))

(define (callback-proc name level len msg)
  (define name* (or name #"???"))
  (set! ffmpeg-log-list (cons (ffmpeg-msg name* level msg) ffmpeg-log-list)))

It doesn’t need to synchronize on anything. It does do two constructions (the pair and the ffmpeg-msg)

And it does do a set! on a list.

(One other place in the code also can set! the list, although it also runs in atomic mode.)

This code seems to be safe most of the time, but occasionally makes things deadlock.

Hmm…I seem to get the same behavior even when I do: (define (callback-proc name level len msg) (define name* (or name #"???")

errr

(define (callback-proc name level len msg)
  (define name* (or name #"???")
  (void))

hmm…here’s any idea. @mflatt, what happens when Racket is already in atomic mode, and an FFI call from another os-thread calls a racket callback. Would the async-apply wait until Racket leaves atomic mode?

@leif the questions you ask when you’re developing video make me scared to do anything FFI related :p

@notjack lol

Its actually not that bad for the most part.

And honestly, the fact that I can even ask those questions is pretty impressive, and speaks a lot to how good the ffi is. :slightly_smiling_face:

@leif I believe you, but I remain cautious :p

lol, fair.

It is always kind of amusing when you have a program with multiple threading systems running around. And you have to remember which mutex is associated with which system to avoid deadlocks…

oh jeez

He, he. Hopefully Sam Caldwell will get some of his concurrency DSLs out there, as that can help eliminate a lot of the problems. )

:slightly_smiling_face:

But ya. IMO, it really is quite fun. ^.^

have no idea who that is but concurrency dsls sound interesting

do you have a link?

Not yet no. He is a PhD student who was doing a lot of stuff with @tonyg (who does seem to actually be on here. :wink: )

https://github.com/tonyg/syndicate

syndicate I have poked at a little

I guess there is that: https://docs.racket-lang.org/syndicate/index.html?q=syndicate

Ah, okay

@leif Yes, atomic mode means that async-apply callbacks must wait

what is the user package scope for? going through the docs it seems to be so different users of the same computer can have different packages installed, but conflict checking is across all installed packages. why would it be useful then?

@notjack It doesn’t work if installation-scope packages depend on user-scope packages, but the intent is that all dependencies go the other way. It also doesn’t work if installation-scope packages change out from under a user. The normal case is that a distribution has installation scope and doesn’t change, and everything else is in user-scope.

@mflatt would it prevent a command like raco pkg update --auto mypkg from updating installation scope packages because that might cause problems?

In a setting with user-scoped packages, normally that’s the default (so raco pkg actions tend not to affect installation scope) and normally the catalog is configured so that an unchanging set of packages are reported for the installation (i.e., the catalog for a release, which freezes all of the packages that are included in the main distribution).

@mflatt I think the main distribution packages are in both the normal catalog and a release catalog; do different installation scopes use different sets of package catalogs to resolve names to sources?

No, they use the same catalogs, but the release catalog is ordered first in the search

I don’t think I understand why there are package scopes then, since the “main distribution packages are frozen” behavior arises naturally due to how catalogs are configured

It’s not about which packages are updated, but about which directories can be written to install new packages. For a multi-user setting, the main distribution can be installed in "/usr/local" and shared among users. But users cannot install new packages there; they need to install packages in their own space, while sharing as much as possible with the main installation.

@mflatt ohhh, so it’s more about machine permissions and administration, instead of isolating packages from each other or dependencies?

yes

how does using a directory as a package scope instead of using the installation or user scopes play into that?

@notjack A directory is meant to be an extra installation-like layer, similar to "/usr/lib" versus "/usr/local/lib".

@mflatt ah, that makes sense. thanks for explaining all this!