@mflatt What is going to happen with raco ctool and Racket modules made in C in Racket 7?

As far as I can tell it seems to not be in the current implementation.

@leif raco ctool is still there for racket7 = “the current Racket VM, but with a Racket-implemented expander”. For Racket-on-Chez, raco ctool will not do anything useful.

Oh, it’s possible that I haven’t set up the part that can load a C implementation of a module in racket7, which is probably what you mean. I’ll have to look into that.

Yup, that is what I was trying to get at. I was talking with @michael.ballantyne about it.

(I noticed that I could us swig to generate c++ bindings for Racket, but it used the sort of C-level Racket modules to do so.)

@leif I hadn’t heard of swig before. I likely will need to use a C++ library for my Racket project and was dreading needing to create a C wrapper for it so swig may be my knight in shining armor.

@abmclin Hopefully it does help.

Obviously it does have to work by generating C wrappers. But swig does at least support racket directly. (Although it still refers to it as mzscheme)

I noticed that part too, I’ll give it a try and see how it goes :crossed_fingers:

g’luck

Swig was created by one of my professors from undergrad

@samth That’s pretty cool.

I wonder what the chances of adding a different flag for ‘racket’ (then the existing mzscheme one)

What is the easiest way to create a synchronizable event that is just like an existing synchronizable event, but after it first becomes ready for synchronization, it stays ready for synchronization and its result is cached? Sort of like a promise, but for events?

It seems like I can get what I want with the following: #lang racket (define (promise-evt evt) (let ([sem (make-semaphore)] [val #f]) (thread (λ () (set! val (sync evt)) (semaphore-post sem))) (wrap-evt (semaphore-peek-evt sem) (λ (evt) val)))) (define chan (make-channel)) (define one-time-chan-evt (promise-evt chan)) (thread (λ () (sleep 2) (channel-put chan 'hello))) (sync one-time-chan-evt) (sync one-time-chan-evt) …which waits 2 seconds, then prints 'hello twice, but I’m wondering if I’m overlooking a better way.

In fact, what I am really trying to build here is an abstraction that represent a box to be filled in later by another thread, but it will only ever be empty for one continuous period, and then it will be filled forever. Again, sort of like a promise, except it is explicitly resolved by an imperative update by a producer thread.

Why not just create a filled box and return it through a channel, then throw away the channel since you won’t need to use it again. It seems unnecessary to need to sync repeatedly if the value never changes.

Multiple threads might wish to synchronize on the same event.

Ahh ok so sync would be the preferred way to coordinate the threads

The promise-evt approach seems good to me. I’m wondering if could remove the need for a thread in the promise-evt definition

I found a thread-less version, FWIW

(sorry, addicted to sync)

In redex, is it possible to specify or render judgments that look like this? e_1 --> e_1* -------------------- E-App1 e_1 e_2 --> e_1* e_2

Also, is it possible to render normal primes instead of subscripted asterisks?

@dedbox I’d be curious to see a threadless implementation.

(define (promise-evt evt)
  (let ([sem (make-semaphore 0)]
        [val #f])
    (choice-evt
      (handle-evt (semaphore-peek-evt sem) (λ _ val))
      (replace-evt evt (λ (v)
                         (set! val v)
                         (semaphore-post sem)
                         never-evt)))))

Maybe the semaphore needs some fiddling to avoid a race