clojure.core/protocol?
It appears that, as of Clojure 1.5, clojure.core/protocol? is private. Does anyone know the reason for this? What's the proper way to tell if something is a protocol? --- Joseph Smith j...@uwcreations.com @solussd -- -- 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.
[ANN] uWSGI support for ring (early stage)
Hi, folks, Yesterday uWSGI had released a ring plugins to give basic support for Clojure webdev. - https://uwsgi-docs.readthedocs.org/en/latest/Ring.html - https://uwsgi-docs.readthedocs.org/en/latest/JVM.html - http://lists.unbit.it/pipermail/uwsgi/2013-March/005549.html - http://lists.unbit.it/pipermail/uwsgi/2013-March/005562.html It is still in early stage, and not production-ready, but we plan to evolve it into mature. JVM and ring support had been settled in the roadmap of next recent versions of uWSGI. And thanks for the great support from unbit team and Roberto, the original author of uWSGI. The reason we, a small team in Beijing, adopt a C-based web container are as below: - We use both python and clojure heavily. - uWSGI work with nginx smoothly. - Easy config and management of uWSGI - We are open source supporters In next few weeks, we will test this ring implementation thoroughly. Any comments and participation are welcomed! Thanks. Regards, Mingli -- -- 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.
Re: ANN: Iota 1.0.2 release (Reducers for text files)
Hi Bernard, I'd certainly like to add support for binary files, but as I haven't had a need for it myself I haven't had a good place to start. As Java NIO's mmap() doesn't support ranges over 2GB, I've had to paste together multiple mmap's to cover files that are larger than 2GB. So if a record ended up spanning two mmap()'s, you couldn't return the raw data as a single object without copying it into a new buffer first. Also, if you provide a fixed record size in bytes for doing the idx offset maths, why do you need the end idx for the current line as well? For example if you say file.bin is full of records each 100B in size, and you ask for the 10th record; don't you already know that the length of the record is 100B? Hope I can help, Alan On Fri, Mar 8, 2013 at 1:44 AM, bernardH un.compte.pour.tes...@gmail.comwrote: Hi, On Wednesday, March 6, 2013 2:53:26 PM UTC+1, Alan Busby wrote: With the release of Clojure 1.5 and it's new reducers, I figured this would be a good time to release a library to help with file IO for reducers. As reducers can only operate in parallel over specific collections, like vec, it requires some work to use them against files. Iota wraps a text files using Java NIO's mmap() so you can treat files larger than memory like a vector. Clojure's normal collection functions (first, last, nth, etc) work, while enabling 1.5's reducer's to operate in parallel for fold. Thanks, I already love your lib ! However, in order to squeeze the last bits of performance, what I'd really need would to be directly access the raw data as byte arrays. The ideal API would provide my function with things looking and quaking like bytes arrays but doing the idx offset maths to directly access the maped data (read-only ), the next-to ideal would provide my function the ref to whole bytes array and give me the start and end idx for current line. (I'd like to port a Java code where the most significant performance boost was avoiding Strings creation when at all possible, which was possible by only peeking at most of the lines). Cheers, B. -- -- 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. -- -- 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.
Namespaced symbols, and errors
Typing the following at a REPL: (str ::junk/junk) (where there's no alias for junk) gives me: RuntimeException Invalid token: ::junk/junk clojure.lang.Util.runtimeException (Util.java:219) RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:219) A couple of things: (i) Invalid token seems a bit curt: doesn't it mean something like no such namespace alias? (ii) A complete aside, but: the interactive REPL obviously isn't disregarding the rest of the line when it gets a token error. Another aside: why does Clojure require :: for aliases but only : for namespace-qualified keywords? Under what circumstance would I use :junk/junkin any way other than to mean ::junk/junk (or :my.namespace.junk/junk, given the appropriate alias)? -- -- 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.
Re: [ANN] Complete authentication app using Compojure and lib-noir
Cool! Thanks for building a nice example app. Paul -- -- 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.
Re: Prismatic Plumbing and Graph Open-Source Release
Hi, On Thu, Mar 7, 2013 at 7:53 PM, Brent Millare brent.mill...@gmail.com wrote: Hi, Very nice work. I'm interested in using graph but just curious in terms of your priorities for future development. Thanks! I noticed that you listed as a todo, you might want to save the body of a fnk which I see as a potential for inlining the bodies and thus eliminating the fn call when creating the final composite fnk. Is this correct? That's right. Thus far the overhead has not been an issue for us, since we usually do a significant amount of work in most Graph nodes, to where the overhead for the input map construction and function call is negligible. So this isn't a very high priority for us currently -- but it shouldn't be much work either. If it's something you're interested in helping with, we'd be happy to work with you on that. Also how would you advice situations when you have mutual recursion (with conditions to bound execution) but still want the compositional power of graph? (like being able to substitute only certain components of the graphs in different situations). I understand that my usage of recursion implies there will be cycles and graph only emits code in topological order so its currently not supported. Is there future support for this or is this outside the scope of graph? Any tips for reclaiming compositional power? How would mutually recursive nodes work, exactly? My guess is that this is probably probably beyond the scope of Graph. That said, you can always do the mutual recursion *inside* a single graph node, where the functions come in as parameters or other nodes (and are thus still easily substitutable), or *outside* the graph (by running (portions of) it multiple times). -Jason -Brent -- -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/UYXcoK0bTNc/unsubscribe?hl=en. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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.
Re: datomic question
On Monday, 4 March 2013 01:50:56 UTC-5, edw...@kenworthy.info wrote: Okay, I think I understand that. Does that mean this code could never work as intended in a Clojure program, only at the repl (which seems a bit of a limitation) or is there a way to make it work as intended, generating a different id each time? Or is the whole approach taken in this code flawed? The tagged literal approach is best used if you need to store the entity and read it back using edn. So it's perfect for using in a data file. However, if you're generating data in code you've already seen how this can cause problems. In that case, you do what Jonas suggests and use tempid (with the appropriate partition keyword. e.g. :db.part/user). The two approaches offer different tradeoffs. tempid is a function, and can only appear in code (not a data file, or anything else read by edn). Conversely, if the the tagged literal appears in code, then it's possible for it to be referred to more than once in the same transaction, which is almost guaranteed to be counter to what you want. Paul -- -- 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.
Re: [ANN] Complete authentication app using Compojure and lib-noir
Double that. Thanks Xavi! -- '(Devin Walters) On Friday, March 8, 2013 at 11:15 AM, Paul deGrandis wrote: Cool! Thanks for building a nice example app. Paul -- -- 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 (mailto: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 (mailto: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 (mailto:clojure+unsubscr...@googlegroups.com). For more options, visit https://groups.google.com/groups/opt_out. -- -- 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.
Re: ANN: Iota 1.0.2 release (Reducers for text files)
Hi Alan, On Friday, March 8, 2013 4:02:18 PM UTC+1, Alan Busby wrote: Hi Bernard, I'd certainly like to add support for binary files, but as I haven't had a need for it myself I haven't had a good place to start. As Java NIO's mmap() doesn't support ranges over 2GB, I've had to paste together multiple mmap's to cover files that are larger than 2GB. So if a record ended up spanning two mmap()'s, you couldn't return the raw data as a single object without copying it into a new buffer first. Also, if you provide a fixed record size in bytes for doing the idx offset maths, why do you need the end idx for the current line as well? For example if you say file.bin is full of records each 100B in size, and you ask for the 10th record; don't you already know that the length of the record is 100B? Indeed, the correlation between txt/binary and char (i.e \n) delimited/fixed length record is very strong. However in my case I want to first handle a \n delimited (txt) file as binary for performance reasons. The context is that I have to consider all the lines of data, but might not have to do heavy processing on all of them, so I want to do as few work as possible on each line (i.e. not construct any java.lang.String). This is in no way Clojure specific, I have two implementations in Java of a small Minimum Spanning Tree program : - one is constructing Strings from all the lines: https://www.refheap.com/paste/12312 - one is using offsets from a raw ByteBuffer : https://www.refheap.com/paste/12313 As most of the lines are not really processed (just sorted according to the last field), being able to only peek at the relevant bytes instead of constructing full blown java.lang.Strings is a huge performance boost. FWIW, as far as performance i concerned, I draw the line not between Clojure and Java but between objects (constructed by copying some data somewhere on the heap) and arrays of primitive data types, because nowadays, cache locality trumps everything (once you got rid of reflection calls in Clojure, obviously). So ideally, maybe 2 x 2 combinations (String / offset in ByteArray) x (char delimited / fixed length) would be needed to cover all the needs. Thanks again for sharing your library ! Cheers, Bernard PS: Is there a rationale for returning nil instead of empty String on empty lines with iota/vec? -- -- 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.
Re: [ANN] uWSGI support for ring (early stage)
This is something really awesome! Clojure Python co-existing together in a single web stack is a very interesting idea. Excited to see where this goes. ~BG On Fri, Mar 8, 2013 at 8:07 PM, Mingli Yuan mingli.y...@gmail.com wrote: Hi, folks, Yesterday uWSGI had released a ring plugins to give basic support for Clojure webdev. https://uwsgi-docs.readthedocs.org/en/latest/Ring.html https://uwsgi-docs.readthedocs.org/en/latest/JVM.html http://lists.unbit.it/pipermail/uwsgi/2013-March/005549.html http://lists.unbit.it/pipermail/uwsgi/2013-March/005562.html It is still in early stage, and not production-ready, but we plan to evolve it into mature. JVM and ring support had been settled in the roadmap of next recent versions of uWSGI. And thanks for the great support from unbit team and Roberto, the original author of uWSGI. The reason we, a small team in Beijing, adopt a C-based web container are as below: We use both python and clojure heavily. uWSGI work with nginx smoothly. Easy config and management of uWSGI We are open source supporters In next few weeks, we will test this ring implementation thoroughly. Any comments and participation are welcomed! Thanks. Regards, Mingli -- -- 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. -- Baishampayan Ghose b.ghose at gmail.com -- -- 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.
Windows Installation
Since I've seen a few recent posts about this experience, I figured I'd share mine: 0a) Install cygwin. I don't understand how any programmer stuck using windows can get by without it 1) Install the Oracle JDK 1a) Add javac to my PATH (I added a symbolic link to javac.exe inside cygwin in a directory that was already in my PATH: ~/bin) 2) Download the lein install script as text from the leiningen home page. 3) Copy it over to my cygwin directory 4) Search/replace to replace the HTML entities with the real thing. I think this was a matter of amp; and gt; 5) It was already executable, so just run it (naming it lein.sh rather than lein.bat was important). I got errors about certificates and permissions. They mentioned instructions about setting up an environment variable (something about something like `export DOWNLOAD=curl --trusting %1`...that wasn't it, but it was along the same lines). I believe that it's some weirdness in the account settings (I have other issues along the same lines in totally unrelated packages), but I suppose I could have just installed some horrible virus. Oh, well. 6) Create a new project 7) Change project.clj to use clojure 1.5 8) `lein repl` inside cygwin didn't work correctly. CLASSPATH was all windows-style, which confused cygwin. So basic clojure.core pieces weren't found. 8a) I suspect I could have set up, say, powershell, to make this work. But that's stupid, and I don't have time to waste on it. 9) nrepl-jack-in inside emacs worked fine. 9a) I'm using an init.el from other systems that already have clojure set up. But there isn't anything fancy or special or customized about it. Just standard configuration stuff that I've found on bare-minimal blog posts 10) Add a symlink to lein in ~/bin. I guess that probably looks big and scary. Windows users are used to a pretty GUI that they ignore and click Next a lot. I dont have a lot of sympathy. I haven't done anything meaningful here at all. But the bare-bones part of the installation process Just Worked. Thank you *so* much to all the people who have worked so hard to make this as simple as it is! Respectfully, James -- -- 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.
Re: Windows Installation
On Friday, March 8, 2013 7:55:59 PM UTC-8, James Ashley wrote: But the bare-bones part of the installation process Just Worked. I agree, things are working well on Windows lately! It's pretty great. I've never bothered with cygwin. Some lightweight alternatives might be the bash shell provided with msys git or Gow. -- -- 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.
Re: [ANN] uWSGI support for ring (early stage)
Seriously awesome! I guess it owes to the simplicity of Ring's spec. I think this will make threading easier with something like Jython on uWSGI. Any comments on how JVM support can be used for better multithreading? On Sat, Mar 9, 2013 at 7:50 AM, Baishampayan Ghose b.gh...@gmail.comwrote: This is something really awesome! Clojure Python co-existing together in a single web stack is a very interesting idea. Excited to see where this goes. ~BG On Fri, Mar 8, 2013 at 8:07 PM, Mingli Yuan mingli.y...@gmail.com wrote: Hi, folks, Yesterday uWSGI had released a ring plugins to give basic support for Clojure webdev. https://uwsgi-docs.readthedocs.org/en/latest/Ring.html https://uwsgi-docs.readthedocs.org/en/latest/JVM.html http://lists.unbit.it/pipermail/uwsgi/2013-March/005549.html http://lists.unbit.it/pipermail/uwsgi/2013-March/005562.html It is still in early stage, and not production-ready, but we plan to evolve it into mature. JVM and ring support had been settled in the roadmap of next recent versions of uWSGI. And thanks for the great support from unbit team and Roberto, the original author of uWSGI. The reason we, a small team in Beijing, adopt a C-based web container are as below: We use both python and clojure heavily. uWSGI work with nginx smoothly. Easy config and management of uWSGI We are open source supporters In next few weeks, we will test this ring implementation thoroughly. Any comments and participation are welcomed! Thanks. Regards, Mingli -- -- 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. -- Baishampayan Ghose b.ghose at gmail.com -- -- 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. -- Akhil Wali # http://github.com/darth10 https://github.com/darth10 # http://darth10.github.com -- -- 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.
Re: [ANN] uWSGI support for ring (early stage)
Seriously awesome! I guess it owes to the simplicity of Ring's spec. Hi, (i am the main author of the uWSGI project), yes the Ring specs have been really enlightening for me. Thanks to them i have managed to built a more sane JVM plugin exporting the minimal amount of features and with solid multithreading support. In addition to this i have based the low-level JWSGI request handler fully on Ring throwing away the old specs (from 2010...): http://uwsgi-docs.readthedocs.org/en/latest/JWSGI.html I think this will make threading easier with something like Jython on uWSGI. currently JVM threads can safely co-exist with CPython threads, see here: http://uwsgi-docs.readthedocs.org/en/latest/Ring.html#accessing-the-uwsgi-api as well as with lua, Mono and Go threads (the other supported languages have basically no threads support) Obviously the python GIL is always there but java threads are not touched by it (unless they are making call to the python vm via the uWSGI rpc subsystem) Any comments on how JVM support can be used for better multithreading? Honestly i have only investigated groovy and scala support (as you can see in the JWSGI docs) but i suppose jython (or jruby) can be adapted pretty easily (even if dynamic languages are harder to adapt to java objects and conventions) By the way, the Ring plugin should be fully usable, what it lacks (or better, what the JVM plugin lacks) is full acces to the uWSGI api. Currently only rpc, signals and a couple of random functions are exposed. (I think caching will be the next area of interest) -- Roberto De Ioris http://unbit.it -- -- 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.
