On Thu, Jul 1, 2021 at 2:42 PM Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote:
> Your "only remaining idea" is what I'd recommend for telling another > place what function to run (that's how dynamic-place works in the > first place). But your [details] sounds worrying. I just tested on my > machine and it didn't happen for me, and I don't think it's supposed > to happen on other platforms either. > *frowns* *goes and checks* My mistake, I misremembered the details. It only happens if you want the platform-specific version of the dialog. If you use the Racket version it's fine but then your interface doesn't match what the user is expecting. https://groups.google.com/g/racket-users/c/wexYxYYU7GE/m/3zXxn6NoAwAJ?pli=1 > Sam > > On Thu, Jul 1, 2021 at 2:36 PM David Storrs <david.sto...@gmail.com> > wrote: > > > > What is the best way to pass a function into a child `place`? > > > > I've got a server function that accepts a dispatch function as one of > its arguments and I need to be able to run the server in a separate `place` > (in the dynamic-place sense) because it's part of a GUI application. > [details] > > > > My initial thought was to start the place and then use > place-channel-(put/get) to move the run-time argument from the main place > over into the child. I immediately realized that doesn't work because > functions are not `place-message-allowed?` values. Next I thought about > using a parameter, but parameters in a child place are set to their > *initial* values, not their run-time values. (Barring a few special cases.) > > > > I considered passing a string or symbol list and then eval'ing it in the > child place. I immediately rejected this idea and told my brain that it > was being bad and it got no cookies. > > > > At this point my only remaining idea is to place-channel-(put/get) a > module name that can be dynamic-required in the child place in order to get > the dispatch function. Is there a better way? > > > > > > [details] > > The Racket GUI library has an issue where e.g. launching an 'Open File' > dialog will freeze all of Racket until the user closes the dialog. This > can cause the server to time out. Since it's all of Racket that's being > frozen and not just the current thread it's necessary to put the server > code into an entirely different `place`. > > > > -- > > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to racket-users+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CAE8gKoemyTeoP2GW5-_h6rGxW_1YcfyCQfHSs9ee98h3pRE4mg%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKoemg5DpdSx-iGcmu-5huM19zCtrdZXkjHHE2JhK7aGpXg%40mail.gmail.com.
