
@gkostejko has joined the channel

No. BC just doesn’t generate code as well as CS.

It’s a shame you can’t set up an affiliate link - I’m going to buy a m1 Mac at this rate…

When reading the docs, sometimes I discover a useful ‘new’ definition that dates back from 6.0.0… I feel like I’m missing most new stuff. How about new releases are accompanied with a automatically-generated brief that describes, since the last release: • all new documented definitions (“Added in version…”) • all documentation modifications (“Changed in version…”) ?

(unrelated) When dynamic-require
attempts to read/visit a module, it raises an exception if the module compiled with a different version of racket. Why doesn’t it fall back to doing as if the module wasn’t compiled at all instead?

how long does a clean build of Racket take? like make CPUS=4

@mflatt Why make the program functional instead of using set! can improve performance so drastically?

Roughly, set!
ed variables do not get put in registers.

Based on Cameron’s comment, it seems like they want it to work on Rosetta out of the box

@wanpeebaw Check out https://docs.racket-lang.org/guide/performance.html

The short answer is that it’s often too late to go back to that

hm. Is there a way to tell dynamic-require
to not use compiled version, apart from deleting .dep files? If so, one could use it first normally, and then if a corresponding exception is raised, try again in not-compiled mode, no?

@ryanc has a package that handles this more transparently

Great idea!

Oh, I see about Rosetta. Still, I’ll ignore that for now.

I’ll time builds more carefully when everything is set up right.

For anyone who uses 64-bit Intel Mac snapshots on Catalina: the ones generated at the Utah site are now notarized (like release builds).

Would be great if we could even scout the docs to generate these retrospectively

In case anyone knows something about signing on Big Sur / AArch64, here’s something that still puzzles me: If I sign a “.dylib”, then I can load and use it. If I sign the “.dylib” and then copy it, the copy does not works. I can’t figure out where that state resides. It’s not shown by xattr
, but it seems connected to the filesystem inode, because I have to delete the bad copy (not just overwrite it) before I can use the same path for a working “.dylib”. Where is that state stored? Is there some way to copy a signed “.dylib” outside of a framework and make it ok?

Alternatively, for my purposes: Is there a way to have shared libraries used unsigned dependencies? I know about com.apple.security.cs.disable-library-validation
, but that doesn’t seem to apply transitively, even if I open the dependency manually with dlopen
first.

Could this be related to the caching of the libraries? Or is the only for system libraries?

I think that’s only system libraries.

The package is called custom-load
.

I am surprised that in racketcs locally defined structs are much slower just because schemify lifts my functions.

It’s not just transitive dependencies. Some libraries work as unsigned with disable-library-validation
, and some don’t, so I’m still missing something there.

Ah, no… the library I thought worked is just falling back to the system-wide library.

Thank you both. @ryanc i’m not clear on the details, but it seems you check the deps before doing any work (which is probably the good general solution). Am I correct that this can be non-negligibly slower?
I was thinking about something more aggressive, in a particular case: I always call dynamic-require in a namespace I just created. So I could call dyn-req, and if it fails with a link error, I could just recreate the namespace and call it again with ‘load-from-source’ (while informing the user about using the fallback mode).
Am I missing something?

Yes, it’s probably slower. I haven’t measured how much.

If my module requires racket
, is it going to check every single dep file in the racket tree?

I’m less confused now on another point: It’s ok to copy a signed “.dylib”. It’s just that I wasn’t signing correctly (left out --timestamp
) in the experiments where I tried copying.
The way a bad state gets permanently attached to an inode is still mysterious and a persistent source of confusion, but it’s less relevant.

I think the problem is that cp0 doesn’t know how to drop the registrations of a constructor function as a constructor for procedure-struct-constructor?
, etc.

Instead of a (weak) take that has all constructors, a better approach would be to attach a tag to the code object for a constructor.

And one way to do that is to encode it in the name. That’s the way that methodness (for error reporting) is attached to a procedure, but that’s ugly.

It would be nice if code objects had a way of storing and reporting flags.

Though it would be nice to eliminate unused struct registration, the problem I met is that struct operations fail to be inlined:https://github.com/racket/racket/issues/3535

Oh, I see what you’re saying

Schemify is implementing the rule that a local function never creates a closure if it’s only used in application position, because some Racket code relies on that performance. I guess a better rule would be that allocating a closure is ok if allocation is happening anyway.

I’ve got a gh action that is trying to run scribble, but I get “Unable to init server: Could not connect: Connection refused Gtk initialization failed for display “:0"” Any ideas what I need to do to get this to work?

Possibly run the process under xvfb-run

Yes, that’s what I do. Note that it’s your code that uses the GUI (probably redex
)

If that’s accurate, you could instead require redex/reduction-semantics

thanks — I need the GUI stuff because I’m using redex/pict

redex/pict
ought not to need the gui, but maybe it does anyway

yeah, I have other redex repos that didn’t need this, so maybe I missed a require redex
somewhere. In any case, it worked with xvfb-run.

@johangwbasson has joined the channel

has anyone encountered this error before while using #lang brag
? Encountered parsing error near #f (token 'no-tokens) while parsing #<path:C:\path\my-file.rkt> [line=#f, column=#f, offset=#f]

@ckipp has joined the channel

Maybe run xhost +local:
? Or export DISPLAY=:0
?

I’m now mostly clear on how signing works, and it starts to seem workable overall. The most surprising piece of the puzzle was reimplementing codesign -s -
for ad hoc code signing (to create embedding executables that will run locally without requiring codesign
to be installed).
… but I’m now I’m unclear on how requiring executables to be signed accomplishes anything when it’s so easy to add an ad hoc signature.

Maybe it closes loopholes when a more restrictive policy is in place? Or maybe it lets them find you if you write malware?

#lang racket/base
(define -c- (make-channel))
(define t (thread (λ()
(let loop ()
(displayln 'HERE)
(sync (thread-receive-evt))
(channel-put -c- (thread-receive))
(loop)))))
(define t2 (thread (λ() (let loop () (displayln (channel-get -c-))))))
(thread-send t 2)
(thread-send t 2)
(thread-send t 2)
(thread-send t 2)
The above program prints 2 just once.
It prints ’HERE twice.
Is this a bug?
Creating the event once only doesn’t make a difference.
Racket CS, 7.9, Windows 10 64 bit.

I don’t generally expect bugs in this part of racket, but this really looks like one. Should I make an issue?

Are you running the program in DrRacket or with plain racket?

DrRacket

Oh, I think you meant to call loop
in t2
.

oh

Oh right, false alarm

Eh, false alarm. I wasn’t looping in the second thread.

One thing that is still mysterious to me is when to use #'
vs when to use syntax/loc
. I see people doing (syntax/loc this-syntax ...)
a lot. Can’t that be the default for #'
?

IIUC, say I have (define-values () 1)
. This is valid syntactically, but will error at runtime, using the source location of (define-values ...)
. So in principle, we only need to use (syntax/loc ...)
for macros that could generate error like this?

By that, I mean, perhaps #'
should tag the syntax object with a placeholder value, and if it’s not specified, the macroexpander will fill these placeholder with the original syntax location.

Man I remember that alert. That was a wild day.

I think I just hit a case like that with fancy-app
the other day

Speaking of #'
a.k.a. syntax
: > If id is not bound as a pattern variable, then id as a template produces (quote-syntax id)
. Just today I made a mistake where I was renaming a pattern variable and missed an occurrence referring to it with #'
. I do this once in awhile. (Also sometimes just make a typo in the first place.) As a result, then it’s just “some random piece of syntax with srcloc in the macro”. Sometimes the consequence is immediately obvious; sometimes it isn’t until the bogus srcloc turns out to matter.
Does anyone else make this mistake?

Today I made the mistake when changing some pattern variable names to be uppercase, thinking it would help avoid problems like this. Ironically. :smile:

I guess I’m just wondering out loud if a “strict” version of this would make sense, that fails loudly if id
is not a pattern variable.

Or if I’m overlooking something really obvious, how other people avoid making this mistake.

I definitely want a strict version

I make that mistake all the time too

Related discussion: https://github.com/racket/rhombus-brainstorming/issues/55

I would think a better place for it is just before closure conversion in chez

That’s an appropriate default if you assume that errors pointing to the source of the macro are always bad, but I don’t think that’s true

When I visited Naughty Dog, they talked about doing something like that

Because they assumed their macros were always correct and pointing to the implementation would not ever be helpful to show to a user

I haven’t read much about this, but an “ad hoc signature” seems to just be a hash of the contents. So it will only protect against modifications to the contents after the hash was attached—as long as the attacker doesn’t update the hash too. I wonder if the hidden inode state that you saw is some mechanism that attempts to prevent an attacker from just modifying the hash.

@ggeneraux has joined the channel

@mflatt Thanks for your hard (and fast) work. Racket compiled perfectly on my M1 Mac when cloned from GitHub. All the packages built and DrRacket CS is running very nicely. Thank you!

I think this is just Big Sur being weird, not about M1. My Big Sur (Macbook Pro 2017) also goes backward too.

That’s really fast

Guys, im stuck with creating language and don’t know what should i change in code to make it work… If someone have free time, can you please review what am i doing wrong?… Thanks! https://github.com/readysloth/REPLify