
I have added “basics” examples to Sketching. I had to use iframes in order to get multiple examples on the same page. Does this approach work for everyone?
Scroll down here: https://soegaard.github.io/sketching/Examples.html

That is so cool!

I haven’t looked at the mailing list lately, so I just wandered over to Google Groups. Some old USENET groups are on Google Groups, e.g., comp.lang.haskell. I clicked on that one and immediately saw messages like the one you’re talking about. The SPAM issue is not confined to the Racket discussion list.

For me (Firefox, Ubuntu, big laptop screen) every example almost fits. Each has scrollbars which only need to scroll a small amount to show the bottom right.
So if I were in your shoes, I could imagine trying to eliminate that? (“‘just’ make the examples a bit smaller”) But I could also imagine that’s a rabbit hole and time suck — it is just fine as-is!!


@greg Thanks - I hadn’t tried it on Firefox. Right now the iframe and the canvas inside have the same size. I might need to pad the iframe a little.

As-is it is 100% fine. Trying to make things “pixel-perfect” and “portable” on the web can be a thankless task. Just wanted to show you, so you could decide.

The bigger point is what you did is awesome!

Well - don’t be too impressed :slightly_smiling_face: I made the examples in Sketching (Racket), but the inlined examples are in P5.js and are from the Processing web-page.

Same deal on my phone, slightly too wide. Also a couple identifiers with red underlines

I hope the red underlines are the five(?) functions that I haven’t documented yet. Worse - some functions are black with no links in the overview. And I haven’t figured out why.

I think that’s correct. Hmm… more for-labels?

It’s a bit tricky. For example fullscreen
is documented, but I can’t for-label
since that would create a dependence on racket/gui
and that’s not available when building documentation on the build server.

@greg I think, the CSS style “border:0” fixed it. :crossed_fingers:

(not live yet)

The fix is now live.

Didnt help too much on mobile (the default zoom on the page makes the text fit, zooming out gives me the whole canvas), but it’s not a big deal there

Tried at work (Win10, Windows Edge). CSS change did not change how it looks, AFAICT.

Hopefully that means it still looks okay in Edge?

(with no border and no scroll bars)

Nor on Firefox. But as @greg pointed out, the work is great, don’t let a little pixel dust be a bother, for now.

Are the Hue, Saturation and Brightness examples supposed to start out black, then fill in as you move the cursor across them?

yes

And the position (y) determines the color.

Yeah, I figured that out. Might be good to add a note that the background stays black until you start to move the cursor over it.

Good idea.

As far as scrollbars are concerned, this is what I see.

Maybe the iframe width,height need to be bigger than the image inside?

I am seeing this in Chrome:

And this in FireFox:

What I pasted was how it looks on Windows on Edge (or Firefox). I just tried Chrome on Windows, scrollbars there too. I’ll try Mac next, then GNU/Linux.

That’s odd. Chrome behaving differently on Windows.

When I inspect the iframe, I see:

Mac Firefox.

Mac Chrome.

Hmm…

And the page is: https://soegaard.github.io/sketching/Examples.html#%28part._examples_color%29
(not the one on http://docs.racket-lang.org\|docs.racket-lang.org) >

yes, I went straight to your http://soegaard.github.io\|soegaard.github.io, didn’t even know it was at http://docs.racket-lang.org\|docs.racket-lang.org

The one on http://docs.racket-lang.org\|docs.racket-lang.org lags behind (due to the build server).

GNU/Linux Firefox -> scrollbars, like Mac

I see one odd thing when I inspect the iframe.

GNU/Linux Chrome -> scrollbars

The frameborder
ought to have been frameBorder
. And it is frameBorder
in the source - but somewhere along the way it got changed.

good eyes!

Yes, it’s unfortunate that google groups is unable to do better here. Probably the only real solution for Racket would be to move to some not-mailing-list solution where people have to create accounts, like Discourse or GitHub Discussions.

Out of curiosity, is there a particular reason why? (eq? (symbol->string 'c) (symbol->string 'c)) ;=> #f
I would have expected symbols to have the string they were build from interned with them such that symbol->string
doesn’t need to build a whole new string each time for the same symbol.

I think this is why: > (let ([z (symbol->string 'x)]) (string-set! z 0 #\c) z)
"c"

Which is arguably a misfeature, but we didn’t make enough strings immutable in the past.

Yes. Back in the day all strings were mutable, so some code mutates the result of symbol->string
.

ty

Fun fact: On Chez Scheme some symbols have no interned string associated. For symbols created with gensym
the string is created only if some function calls string->symbol.

Hi. Please help me translate this time format into hour / minute / second … (require gregor)
(define a (iso8601->moment "2021-07-29T14:34:28.984743476Z"))

Do you want to get a moment from hour:minute:second format? parse-time
with “HH:mm:ss” as the pattern (you can’t parse it into a moment because it needs a date) Do you want to get a
into that format? ~t
with the same pattern

Thanks. Getting closer. I tried this and got this error… See below
(parse-time "2021-07-29T14:34:28.984743476Z" "yyyy-MM-dd'T'HH:mm:<http://ss.xxx\|ss.xxx>")
Unable to match pattern [xxx] against input "984743476Z"

the time zone is throwing it off

I have added a scrolling='no'
so maybe the scroll bars are gone now?

Maybe everyone’s already seen this but https://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time

Hi all, I need to parse datetime for RFC–3339 format (which have nano-second precision). Any recommendation?

It looks like this 2021-07-29T14:34:28.984743476Z

Didn’t your original code do that?

parse-time
can not handle nano-second it seems so that is why it does not work for me

Sorry, original original code. I suggest parse-time because I thought you were adjusting the code to a different input format.

No worries. I don’t really need nano-second precision.

Have another question.

How to pause execution for 20 seconds? Using sleep 20
or sleep 2000
?

Are you sure it’s the precision it’s bailing on? the error Unable to match pattern [xxx] against input "984743476Z"
looks like (to me) as though it’s bailing on the “Z” (zulu time zone) at the end, since it’s not a digit.

(require gregor)
(define a (iso8601->moment "2021-07-29T14:34:28.984743476Z"))
(~t a "HH:mm:ss")
(~t a "h:mm:ss a")
Sleep’s parameter is seconds so you’d use 20

(Oh, if you were asking how to get individual components from the moment, it’s a struct, so (moment-year a) => 2021
etc)

((or it does not export that, so that’s not the way, oops))

->year
, ->nanoseconds
etc. Final answer.

Ok. I am getting closer to what I want though. Thanks for all the help.

By the way, how to set the timezone? I live in the east coast so need to set to EST (New York). I try this but did not work …

(parameterize ([current-locale "en"])
(displayln (~t a "E h:mm a")))

(adjust-timezone a "America/New_York")
will return a new moment using the given timezone (Can also use “EST” or the UTC offset in seconds)

(though if you do then it will be wrong because NYC is on EDT right now)

(current-timezone)
would be the way to make it match the current system settings, whatever they might be.

I just checked on Mac/Firefox and the scrollbars are gone.

Thanks for checking.

Also gone for Mac/Chrome, Linux/Firefox, Linux/Chrome, Win/Edge, Win/Firefox, Win/Chrome.

@samth I think here’s an example from today—is this a bug I should file? ~/herbie $ racket src/herbie.rkt --seed 12 report bench/hamming/ /tmp/out/
loading code: version mismatch
expected: "8.2"
found: "8.1"
in: /Users/pavpan/herbie/src/compiled/herbie_rkt.zo
~/herbie $ raco make src/herbie.rkt
src/programs.rkt:3:23: collection not found
for module path: rival
collection: "rival"
in collection directories:
/Users/pavpan/Library/Racket/8.2/collects
/Applications/Racket v8.2/collects/
... [168 additional linked and package directories]
compilation context...:
/Users/pavpan/herbie/src/programs.rkt
/Users/pavpan/herbie/src/syntax/rules.rkt
/Users/pavpan/herbie/src/plugin.rkt
/Users/pavpan/herbie/src/herbie.rkt
location...:
src/programs.rkt:3:23
context...:
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:612:0: compile-zo*
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:410:15
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:399:12: build
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:375:0: maybe-compile-zo
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:209:0: compile-root
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:145:4: compilation-manager-load-handler
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:612:0: compile-zo*
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:410:15
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:399:12: build
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:375:0: maybe-compile-zo
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:209:0: compile-root
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:145:4: compilation-manager-load-handler
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:612:0: compile-zo*
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:410:15
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:399:12: build
/Applications/Racket v8.2/collects/compiler/private/cm-minimal.rkt:375:0: maybe-compile-zo
...

Those errors both look like they would be the result of installing Herbie and it’s dependencies in 8.1, then switching to 8.2 but not installing the necessary dependencies

Right, I’m sure of it. I think the dependency is local.

So is this an error I should report or is this expected behavior?

That’s expected behavior

as in, if you ran racket -c src/herbie.rkt
to not use zo files at all, you’d still get an error about rival
being missing.

Ok so after I did raco pkg install
it should still work?

if you do raco pkg install rival
then the raco make
should work

or whatever raco pkg
command you need if rival
is local

Ok yep. I think I would have figured it out without help but I seem to have done every wrong thing too

Ok, another question—do I understand correctly that I have to raco make
the module I run and also any other modules that are dynamically required?

If the dynamic-require
uses lazy-require
or something else built on define-runtime-module-path
then no

Otherwise yes

Basically if herbie works with raco exe
already (which I think it does) then raco make
ought to just do the right thing.

But I might be remembering incorrectly

ooh interesting

Will read up on define-runtime-module-path

I recommend lazy-require
; it’s super-easy

Any diff between define-runtime-module-path
and define-runtime-module-path-index
here?

My eyes glaze over when I read the docs

lazy-require
doesn’t work for us because module loading has effects but doesn’t export anything.

define-runtime-module-path-index
will save a little more startup time

compared to define-runtime-module-path

ooh that is attractive

But it won’t impact raco make
visibility, right?

Right

Wait that seems to be false

define-runtime-module-path
does the “right thing” for raco make
but define-runtime-module-path-index
does not.

That strikes me as wrong, but I might be mistaken about the constraints.

@mflatt should define-runtime-module-path-index
also collaborate with cm
?

That sounds likely. I suggest trying that and seeing if anything goes wrong. We may have to think more about backward compatibility, but if making the change doesn’t go wrong right away, then my guess is that it’s compatible enough.

Looking at the code, it doesn’t actually collaborate with cm
, it just expands to (require (for-label p))
. So I have to remember how the collaboration goes.

@mflatt Out of curiosity, is there any information written up anywhere about which issues were resolved by switching to the sets-of-scopes expander? (Ideally I’d also like to know why the marks-and-renamings expander failed on those examples, but that sounds like hoping for too much.) The only concrete thing mentioned in Bindings as Sets of Scopes appears to be <http://web.archive.org/web/20160430005218/http://bugs.racket-lang.org/query/?debug=&database=default&cmd=view+audit-trail&cmd=view&pr=14521|PR 14521>, which unfortunately doesn’t include any context on where specifically the old expander went wrong.

I feel like the free-id difference for quote-syntax
in 3.2 of the sets of scopes paper (web version) is very interesting but that’s not really an issue.

Yes, I essentially just want to better understand what motivated the replacement of the marks-and-renamings expander. As far as I can tell, there are at least two broad categories of motivation: 1. The old expander discarded essentially all lexical context when expanding a submodule with a non-#f
module path. In contrast, the sets-of-scopes expander allows macros to add scopes to a submodule body and have those scopes affect its expansion. To be honest, it is not immediately obvious to me why you would want this, because any local bindings created in such scopes would necessarily be out of context in the submodule, and any module-level bindings could be brought into scope in other ways. I suppose it could be useful in niche circumstances to use scopes created with make-syntax-introducer
to distinguish bindings within the submodule, but I’m not sure what else. 2. The marks-and-renamings expander seems to have struggled with macros that “smuggle” identifiers via compile-time state. A handful of macros had to use very tricky functions like syntax-local-make-delta-introducer
and syntax-local-get-shadower
to adapt the smuggled identifiers to their new lexical context, since the proactive nature of the addition of syntax marks combined with the strict mark set equality test for applying renamings meant that it was hard to perform significant code motion without causing a lot of problems. I am considerably more sympathetic to this frustration, though such macros do seem to have been exceedingly rare.

as an outside user, the biggest benefit of the new expander for me has been that I can actually understand the set of scopes model

@niko has joined the channel

Hello all! I have a Dr. Racket question, is this an ok place to ask it?

Yeah, go ahead

Is there a way to select the current s-expression?

Also: is there a good channel for redex discussion? I didn’t see an obvious one :slightly_smiling_face:

it gets highlighted, but I’d often like to copy-and-paste it

What do you mean by that?
Navigation by s-exp can be done with alt-left and alt-right. And with shift, you can select things

let me try that

E.g.,
(+ (+ 1 2)\| 2)
where \|
is your caret.
Then you can shift-alt-left to select:
(+ [(+ 1 2)] 2)

it looks like shift-alt-left does what I want, yes, thanks!

No, I don’t think there’s anything you wouldn’t have already found, like the paper.

Some things fixed, probably like that old issue, were more of a quality-of-implementation change than a change to the underlying model.

General is totally fine!

Anecdotally, I find scope sets much easier to reason about. The immediate immediate example I have on hand is implementing define*
-style binding for a Rhombus experiment. It was much easier than the last time I tried. I’m expecting local require
to “just work” in a similar way, although I haven’t actually tried it, yet.

But you’re looking for more concrete examples, and I can’t point to anything that isn’t in commit messages.

This is the actual motivation

Thanks, that’s still helpful. I agree that I find scope sets easier to reason about. I just find it somewhat intriguing how much that is the case given that, intuitively, marks-and-renamings seems like a more direct interpretation of what “hygiene” means, intuitively. That is, the hygiene condition means that a let
should only affect the parts of its body that were lexically inside the let
in the source program, so intuitively we need some way to tell which parts meet that criterion and only apply the let
’s scope to those pieces. In marks-and-renamings, the question of which pieces were/were not lexically inside the binding form is directly answered by marks, and the mechanism by which the scope is applied is renaming.
Sets-of-scopes actually seems significantly further removed from that intuitive idea: we don’t bother to restrict the effect of a binding form to the pieces lexically contained within it, we just apply it everywhere, haphazardly, even to pieces that came from completely unrelated lexical locations. Then we invent completely synthetic scopes that correspond to no lexical region whatsoever to help disambiguate post-hoc. (And this indirect correspondence with the intuitive meaning of hygiene even causes concrete complications, such as use-site scope pruning in definition contexts.)

The general takeaway I’ve been converging towards is that marks-and-renamings seems to provide a more direct interpretation of hygiene, but sets-of-scopes provides a much more intuitive definition of scope. The former is largely intuitive for strictly hygienic macros, but it provides no underlying abstraction that captures what a scope actually means in an expanded (or partially expanded) program, so hygiene bending and explicit scope manipulation becomes incredibly tricky. Sets-of-scopes has a less direct correspondence to hygiene as it is traditionally described, but it’s possible to reason about what it means even when you don’t use it to implement hygiene, which is to say it’s more like a cohesive framework that hygiene is constructed on top than a hygiene algorithm per se.