Hello

@stamourv JFYI:

#hash(("semver" . (success test-fail))
        ("racketscript-extras" . (no-docs build-fail))
        ("wrap" . (install-conflict build-fail))
        ("css" . (success test-fail))
        ("racketscript" . (no-docs build-fail))
        ("turnstile" . (success test-fail))
        ("racketscript-compiler" . (no-docs build-fail)))

those are the current build regressions

I believe that racketscript and racketscript-compiler are https://github.com/racket/typed-racket/issues/579

wrap is https://github.com/racket/typed-racket/issues/581

semver is https://github.com/racket/rackunit/issues/60

turnstile is a timeout in the test suite

css I don’t understand the test failure

also, turnstile passes on Travis on HEAD so we probably don’t need to worry about it

@samth the rackunit issue is caused by one of my changes to the typed rackunit code in typed-racket-more. On a semi-related note, what would you think of moving the typed rackunit wrapper into the racket/rackunit repo?

zenspider: no I don’t think there’s any “readers guide” that connects the book to “modern day redex” :slightly_smiling_face:

but I don’t remember the syntax being confusingly-different — I think using the book you just miss out on new things like #;binding-forms

@notjack I’m not sure what you’re suggesting. I don’t think that rackunit should depend on typed-racket

also, what needs to change to fix that regression?

Not positive on the fix yet, haven’t had to time for more than a glance.

ok

Does anyone know if async-channel-put can be called in atomic mode?

About the suggestion, I mean making a rackunit-typed package in the rackunit repo and having typed-racket-more imply that package

@notjack that seems reasonable to me

Actually, never mind. I can probably just use call-with-semaphore

Ahh interesting I wasn’t aware that the current version of Redex had diverged from the book version. Good to know so I’ll be sure to pay attention carefully when I’m tackling the book.

@leif: Neither async-channel-put nor call-with-semaphore seem like a good idea in atomic mode, since they can block. If call-with-semaphore can can’t block in your use and you’re already in atomic mode, then would the semaphore serve a purpose? I guess you could have a function where you know the call-with-semaphore won’t block in cases where the function is called in atomic mode, but that sounds unusual.

@samth I think https://github.com/racket/typed-racket/pull/583 isolates and fixes the rackunit issue. As an aside, rackunit’s test suite code is probably due for quite a bit of housekeeping..

@mflatt Woops, I meant, I can get away with using call-with-semaphore, instead of call-as-atomic in this case.

I absolutely agree that call-with-semaphoreis a bad idea to do in a call-as-atomic.

Although the async-channel-put I was thinking of using had an unbounded buffer size.

Oh, that makes sense!

Okay cool, thanks.

@helga you should repost these in #summer-school … I think you can do that in the ... menu