Does racket have any built-in parallel mapping/for loops; I’m not seeing any obvious ones in the docs?

Parallel as in the body is run in multiple concurrent threads?

yes, and the result is the result of each body/thread - in order - joined properly into the final list/whatever output

if i need to roll my own, that’s fine, but thought there may be something already there

I don’t think there is anything builtin - but I am almost sure I’ve seen a package for that at some point.

Maybe https://docs.racket-lang.org/rparallel/index.html ?

Or https://docs.racket-lang.org/pmap/index.html

yeah, saw those while trying doc searches. maybe i’ll look at them

the for loops having built-in #:parallel #t as an option would be exceedingly welcome, tho :wink:

<file:///C:/Program%20Files/Racket/doc/reference/futures.html?q=for%2Ffold#%28form._%28%28lib._racket%2Ffuture..rkt%29._for%2Fasync%29%29|11.4 Futures>

I wonder if that will do what I want

If your body is simple, then futures might be it.

I think #:parallel #t in general is tricky because there are (at least) 3 choices, threads, places, or futures

“Have you ever had a wish/idea about something I could feature/present in Racket News? Now it’s a great time to let me know. https://github.com/pmatos/racket-news/issues/new?title=I%20have%20an%20idea\|https://github.com/pmatos/racket-news/issues/new?title=I%20have%20an%20idea ” - @pocmatos on Twitter

There is for/async, which someone showed me recently, but I doubt it has things similar to what is desired

https://news.ycombinator.com/item?id=27531508

racket is not well suited for automagically parallel loops, and even if it were it’s easy to misuse that kind of thing

are you trying to parallelize IO work or CPU work?

Thanks a lot for sharing this!

https://lobste.rs/s/6rnyn9/why_i_no_longer_contribute_racket

IO. CPU wouldn’t work well since racket doesn’t use os threads.

I got something simple enough using threads and a simple for loop.

If you are CPU bound you can (possibly) use places.

I’m trying to create a text-field% that auto selects its text contents when clicked into, like a browser address field. The following code attempts to do that but has-focus? always returns #f, even after the field should already have focus. What am I missing here? (define address-field% (class text-field% (super-new) (inherit get-editor has-focus? focus) (define/override (on-focus on?) (eprintf "on-focus ~a -> ~a~n" (has-focus?) on?)) (define/override (on-subwindow-event recv event) (if (send event button-down? 'left) (if (has-focus?) (begin (eprintf "already has focus~n") (super on-subwindow-event recv event)) (begin (eprintf "selecting all~n") (super on-subwindow-event recv event) (focus) (send (get-editor) select-all) #t)) (super on-subwindow-event recv event)))))

Basically, every click in the text field follows the ‘then’ branch of on-subwindow-event and re-selects all the text.

Is (listof any/c) as fast as list?

Do you mean when used as a procedure (definitely not) or when used as a contract (maybe)?

As a contract

> (coerce-contract 'a list?) (listof any/c) > (coerce-contract 'a (listof any/c)) (listof any/c)

what I really want to know is if listof is smart enough to turn (listof any/c) into just a simple list? check on the contract’s input rather than pointlessly looping through it to apply any/c to each element

I timed it and it looks like (listof any/c) does loop through the list

> I timed it and it looks like (listof any/c) does loop through the list That would make sense because to see if something is a list of something, it must definitely be a list. :slightly_smiling_face:

My understanding is that list? must go through the whole list to check if it’s a proper list and not something where the second item in the last pair isn’t '(). (Please correct me if I’m wrong!)

On a related note, I had once used first on a list and the program ran much faster when I replaced first with car. I think first has a contract to check whether the argument is a list, so first iterates through the list. On the other hand, car applies to pairs in general and just returns the first item of the pair.

(Probably car implicitly checks whether the argument is a pair, but that should be much faster than checking for a list.)

> so first iterates through the list Technically yes, but the result is cached in a way that if you call these operations several times, the amortized cost is O(1)

There used to be a version where the cache is computed incorrectly, so first is very slow. It’s fixed a while back though. Not sure if your observation that first is slow is due to that bug.