Hi, Yes, I have looked at core.async. I'm assuming you mean sticking events inside a channel and providing the channel for the user to use? I decided against it for two reasons:
- core.async is still experimental, as far as I can tell. - What I'm doing currently is similar: have a LinkedBlockingQueue of events, with two access functions wait-event (blocking on empty queue) and poll-event (non-blocking with timeout). This seems adequate and simpler for what this library needs. It might just be that I don't see what I'd have to gain from using core.async. Feel free to convince me otherwise. Thanks, Vincent On Wed, Sep 25, 2013 at 1:50 AM, Adam Clements <adam.cleme...@gmail.com> wrote: > Have you looked at core.async for shuttling asynchronous events back and > forth. This sounds to me like the sort of thing it was designed for > > On 10 Sep 2013 06:30, "Vincent Chen" <noodle...@gmail.com> wrote: >> >> Hello everyone, >> >> XCLJB is a Clojure language binding for the X Window System, similar >> to the XCB (the X protocol C-language Bindings). It allows programmers >> to communicate with and write GUIs for an X server in Clojure, without >> having to drop down into C. >> >> Source code, README, and examples: https://github.com/noodlewiz/xcljb >> >> Leiningen dependency information: >> >> [xcljb "0.1.0"] >> >> As the version number indicates, this is a developmental release. This >> means >> - Things are usable, but not yet feature complete. >> - API not necessarily stable, though I won't break compatibility for >> no reason. >> - Comments, suggestions welcome. >> >> Open problems looking for suggestions: >> - How should I signal errors? XCLJB, like XCB, is mostly >> asynchronous. Currently sending a request will immediately return a >> Clojure promise. The promise will be delivered with either a reply or >> an error when they arrive, this allows multiple requests to be sent >> without blocking (this is the asynchronous part). I'd like to raise an >> exception when a user deref the promise and the promise is an error, >> but there seems to be no way of doing so. Should I make my own promise >> type by implementing clojure.lang.IDeref? Is there another way of >> achieving what I had in mind? >> >> - Is there an easier way to match against records? Events are >> currently implemented as records, so event loops would have to look >> like >> >> (ns ... >> (:import [xcljb.gen.xproto_types ExposeEvent KeyPressEvent])) >> (while true >> (let [e (wait-event conn)] >> (condp instance? e >> ExposeEvent >> ... >> >> KeyPressEvent >> ... >> >> nil))) >> >> I'd prefer not to make my user import the event types as if they >> are Java classes. Is there a more Clojurey way of doing record type >> matching? Is there a better way of implementing events? >> >> Regards, >> >> Vincent Chen >> -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
