Hacker News new | comments | show | ask | jobs | submit login

"Finally, many Racket tools depend Racket’s “eventspaces,” which are multiple process-like entities in the same virtual machine, each with its own GUI event loop. Implementing eventspaces on top of modern GUI toolkits turns out to be tricky, because the toolkits insist on a single event-loop per process and they cannot tolerate event-loop actions during certain callbacks."

I can not wait until this is fixed. I can't hardly use toolkits anymore because I keep insisting on programming in languages with sane concurrency stories and that drives the toolkits insane.

(I fully acknowledge the scope of my request and further fully acknowledge that this will almost certainly require something written from scratch. And that writing a toolkit from scratch is a tall order. And that now's a bad time to start trying because the alternate concurrency stories are in flux and it's not really a great plan to write something that works in Haskell but can't work in Erlang or Racket. And also now's not the best time because the very graphical underpinnings in Unix are now being called into question and, given that this is a multiyear project, it could build on X only for X to be on its way out.

But still, I can't wait.)




It is fixed in QT.

"Each QThread can have its own event loop. You can start the event loop by calling exec(); you can stop it by calling exit() or quit()." http://doc.qt.nokia.com/stable/qthread.html

I've used this successfully.


it sounds like if you use the racket 5.1, it is fixed! (in that you don't need to deal with that restriction).

That being said, that certainly is still an obstacle if you're preferred lang isn't scheme/racket. Perhaps their wrapper code could be factored out as a new abstraction layer for these gui tool kits?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: