@samth it has been reported on 2nd of August: https://github.com/racket/drracket/issues/131

Could anyone with more experience using WebSockets and custodians take a look at this issue https://github.com/tonyg/racket-rfc6455/issues/7 and the corresponding pull request? Thanks. /cc @tonyg

@githree If that’s your report, more detail would be great

@samth is there a way to force the migration again (I have all packages migrated now) or do I need to reinstall Racket?

@githree I’m not sure

Ok, I will try reinstall

@samth it appears some individual package installation is sufficient to crash DrRacket - I just did it with installing racketscript from gui

more details on the github issue

great, thanks

what happens if you remove and then reinstall that pkg from the command line with raco pkg install?

command line install works with no problem/no errors

ok good to know

@samth I’ve just tried to install Racketscript from command line again this time with no administrative rights for cmd.exe - it resulted in access violation. If that’s the main issue then running DrRacket with administrative rights didn’t help to alleviate problem.

@githree I doubt that I can figure out further what’s going on — probably @mflatt or @robby would need to take a look, and I think they’re both traveling today

No worries - I am fine with my installation, just tried to narrow down the problem.

@notjack No, protect-out is for preventing untrusted/restricted code (eg in a sandbox) from importing things that would let them break out of the sandbox, crash the Racket process, etc. For example, ffi/unsafe and racket/unsafe/ops protect most of their exports (although it’s hard to tell from the source, since most of the exports are just re-provided from built-in modules). Were you thinking of syntax-protect instead?

@ryanc ah yes that’s the one I was thinking of, I got the two mixed up

I admit I don’t know the syntax arming system as well as I probably should. Hackett’s typeclass dictionary elaborator currently works by recursively taking syntax objects apart and putting them back together again, and I’m pretty sure that will break on code that refers to macros that use syntax-protect.

I’d be interested in any references explaining the motivating reasons for having a syntax arming system, I’ve browsed through the online documentation but don’t really understand the purpose of having such a feature.

It seems weird to me that syntax could be dangerous but then you have people hacking strange things people least expect to be a threat

The purpose is so that macros can serve as safe abstraction barriers. For example, a macro can expand to some identifier that is not exported by a module, call it private-id. The module that defines the macro may expect that users will never be able to call private-id directly, since the macro enforces some invariants that could be broken if private-id were invoked on its own.

A naughty/malicious user could expand a use of the macro using local-expand, then break the syntax object apart and pull out the private-id syntax object. That identifier could then be placed within another syntax object, allowing the malicious user to use private-id without conforming to the invariants enforced by the macro.

The syntax arming system prevents that from happening, since the macro author can protect the syntax object with a code inspector that a malicious user will not have access to. That way, breaking apart the syntax object will taint the resulting syntax, and the user will not be able to get access to private-id by cheating.

ahhh that finally makes sense to me

so that’s how macros are able to prevent users from abusing their own identifiers that are created at expand sites

I thought that was all due to module system being able to prevent private identifiers from being exported or otherwise used not as prescribed by macros but I’m now seeing that syntax arming has a role to play regarding that.

imagine if you exported a function and someone was able to inspect it and get all internal helper functions it called, and then call those helpers directly while skipping contracts and the module system, and they could do that without reflection

Yes. The tricky thing is that Hackett’s elaborator needs to walk an entire syntax object and replace certain bits of it. The current implementation is sort of a hack.

I think I might be able to do something by explicitly disarming/rearming syntax, but I don’t know how to arrange to have the right code inspector.

@lexi.lambda do you think defining typeclass methods as syntax parameters might get around that? so the elaborator could parameterize them to the expected types?

or using a syntax parameter to communicate with the methods indirectly

ok then one would apply a syntax guard/armor or whatever it is, to those private internal identifiers that are inserted at expansion sites, to prevent users from being able to directly use those identifiers? The armor system automatically detects non-legal use or does macro has to inspect to verify identifiers are being properly used along with assistance of the armor system? I recall seeing something about syntax being tainted(able)

@notjack The trouble is that the elaborator has to run after typechecking, and typechecking is expansion. The constraint solver looks at fully-solved types, which are only known after the typechecker finishes its primary pass.

So what I really want is a delimited/multi-phase expansion process. I want to be able to tell local-expand to expand something recursively, but stop when it sees a certain identifier. Currently, that isn’t possible.

The stop-list argument to local-expand sounds like what I want, but using the stop list prevents the macroexpander from recursively expanding things like definitions.

This is one of the main things I want to discuss in-person with some people at RacketCon. :slightly_smiling_face:

good idea :P

indeed, sounds like one of those that are best solved with in-person help

@abmclin Yes, the macroexpander will “taint” armed syntax objects that are pulled apart (using syntax-e) without first being disarmed. Tainted syntax objects cannot be used in the expansion of a macro; the macroexpander will halt with an error.

Using the cute dye pack analogy, opening a syntax object without disarming the dye packs first causes the dye packs to explode.

whoosh! Very cute

https://en.wikipedia.org/wiki/Dye_pack

racket folks love their analogies

haha yes, pretty much the imagery that’s occupying my mind

I’m guessing there’s no way for malicious users to disarm syntax. The macroexpander somehow arranges for the original macros to only be allowed to disarm syntax they create?

That’s the part I understand less well. There is a hierarchy of code inspectors that have privileges to arm/disarm syntax objects, but I don’t fully understand how they work at the moment.

completely unrelated: the static information bound by struct is a struct-info value and the docs for struct-info say not all of the predicate, accessors, and mutators might be known. When can that happen? I can only construct situations with struct where they’re either all bound or the transformer binding itself isn’t created. Does it only apply to “custom” infos and not those created by struct?

@abmclin http://docs.racket-lang.org/reference/modprotect.html

@notjack IIRC, it can happen if you use #:super super-expr instead of super-id, since #:super provides the superclass structure type via a dynamic runtime expression.

@lexi.lambda that makes sense, but the dynamic expression would fall into the category of things that make custom infos and not things that use infos created directly by struct right?

@lexi.lambda thanks for the link

@notjack Not necessarily. You can get access to the struct info for a struct-defined structure as a runtime value by using the struct:struct-id identifier.

and for the clear explanation

@notjack I think modern Rackets also make the struct id itself serve as a reflective struct-info object using the properties system, but I forget if that’s true or not.

@lexi.lambda wait I think I just got it - the #:super option accepts the runtime reflective information (struct-type?) but the transformer binding has the static reflective stuff (struct-info?) and only the latter contains identifiers

Right.

those two categories of info should really be called out more in the docs

The docs for structs are a little confusing. My guess is because the struct system has evolved a lot over the years. :)

for one, it explains why you can’t get field names at runtime which I bet is surprising to a lot of racket folks the first time they find that out

Structs, according to the Racket runtime, don’t have any notion of field names. If you look at make-struct-type, you will see it defines an accessor function that accesses fields by index.

yes but lots of forms have the ability to do stuff with struct field names, they just do it at compile time with the reflective info

it’s easy for people to not get that distinction, is my point

Right. Struct accessors are a concept entirely defined by the struct macro, which adds a static information layer on top of the runtime values.

and it’s even more confusing because the struct static info only uses “accessor” identifiers, the original “field” identifiers are not preserved, so forms like struct-copy will construct the accessors from the field names themselves

Hmm, it looks like I was slightly wrong: modern Rackets do not make the constructor bound by struct a valid struct-type? value, only the struct:id identifier.

And yes, struct-copy is totally broken.

(Unfixably so.)

I mean, there’s no way for struct to define accessors that don’t fit the struct id + field id pattern

(I hope)

https://github.com/racket/racket/issues/1399

yeah that

I want to expose an api like struct copy in something though; guess that just means I need to provide an option to override the “inferred magic accessor binding” thing

gross to use though

I got deep into all this when I wrote syntax/parse/class/struct-id. :)

which is exactly what I’m using right now that led to this :) thanks btw

throwing some syntax classes in there for doing things with fields might be nice

today is one of those days where I’m really grateful for syntax-parse :)

Leif and I sometimes talk about writing a Racket play

it wouldn’t be about Racket per-se

but all the characters would be from the Racket docs

plumbers, custodians, security guards, will executors

it sounds like it would play out as a revolution by an under-appreciated working class

You need a breach of contract as a plot point.

@stamourv slack needs a way to edit a message and make it point to the thread you meant to reply to :)

Threads?

threads ;)

@royall welcome!

In that case who would be the privileged class? Lambda, cond, struct, cons?

clearly struct represents the existing social hierarchy

I heard that some code inspectors were arming syntax objects. big if true

My employer has tasked me with giving a training presentation to my coworkers about 10 days from now. I think I’m going to build it with lang #slideshow

Hope this is a good idea