
I just want to clarify an assumption of mine: mutable struct #:auto fields cannot be funcationally updated (due to lacking a constructor). Is this correct, and if so does anybody know the origin or use-case of #:auto fields?

Related discussion from a couple of weeks ago: https://racket.slack.com/archives/C06V96CKX/p1605543178186000?thread_ts=1605494991.169300&cid=C06V96CKX

Guys, sorry for bumping, but do you have any suggestions to this or following message?…

I stuck :(

This all looks great, I would say anything new is great, and rackety is fine (vs. scala-y or haskell-y). My only small point was that in everything I do at work, I [almost] always have to handle the case where something didn’t happen as expected. Regexps are kind of a trigger word for me. They’re perfect when the input is perfect. Much of my Scala code dealing with regexps has the pattern “did we match?” yes -> “life is great”, no -> “log it, recover and move on or give up,” the latter decision being a matter of business logic. For example, some NWS bulletins have near the top a VTEC section that looks like this: NCC117-201600-
/O.EXT.KMHX.FL.W.0088.201121T1800Z-000000T0000Z/
/WLLN7.1.ER.201121T1800Z.201124T1800Z.000000T0000Z.NO/
754 PM EST Thu Nov 19 2020
and if they do, that’s great, but if it’s malformed (rare, but happens), we can move on. With polygons (later in the message), sometimes they’re super important (tornadoes, severe thunderstorms, floods, …) but we never want to abort processing a message just because a polygon has a problem, we always want to get the substance of a message out, but we do want to abort processing if an alert is so messed up there’s nothing useful we can do with it, while at the same time logging the event as problematic while also super-important [so a human figures this out]. I was thinking of incoming missiles and the importance of figuring things out even if the info is confusing, and then I just remembered the real public alert message (in Hawaii a few years ago) when a test missile defense alert was mistakenly sent out as real-world, causing real widespread panic. My sister-in-law happened to be in Hawaii on vacation and was not at all pleased. All that trouble from what was, inside the computer, represented by a single 0/1 bit, although the cause was human error.

#:auto
is an old and bad feature and you shouldn’t use it

I tried running that and I get a different error

(strlen "hello, world"): unbound identifier

@samth yup, thats because yesterday i changed typo in function call, but main problem persists:
I want evaluate this expression only when ffi-definer is ready (in runtime phase)

scribble idea I’m excited about: dark mode theme for rendered docs https://github.com/racket/scribble/issues/285

@kintiger2020 has joined the channel

On the bright side, at least there was never a #:nullable
. :simple_smile:

scheme_set_original_dir
does the trick on BC. Thanks again!

I’ve been able to start DrRacket on an M1 MacBook, although I still have battles to go with code signing before the libraries will work on anyone else’s machine. I’ve spent most of my time today trying to get the makefiles and other tools to navigate the code-signing requirements. It really is fast. Chez Scheme compiles itself in under 5 seconds, which is almost twice as fast as my 2-year-old x86_64 MacBook. DrRacket starts up so quickly that the splash screen is superfluous.

Did you try the supposedly-working rosetta version?

Doesn’t that require you to be a beta tester?

I haven’t tried making things work with Rosetta

@mflatt Does Racket BC also has similar option like PLT_CS_COMPILE_LIMIT=100000
which prevents compiler or jit-compiler kicks in (causes the slowness in BC version)?