I'm very happy to announce the official release of Prudence 1.1.
http://threecrickets.com/prudence/
Prudence is a container and platform for scalable RESTful web
applications and services. It features powerful HTML generation,
letting you insert Clojure
I'm very happy to announce the official release of Prudence 1.1.
http://threecrickets.com/prudence/
Prudence is a container and platform for scalable RESTful web applications
and services. It features powerful HTML generation, letting you insert
Clojure scriptlets into web pages, or write
I have to agree with this. In fact, it would be much easier to
integrate into Clojure than JRuby (or other JVM languages).
I know the Clojure Java source code pretty well, and wouldn't mind
playing with it a bit to see how feasible it is.
The ideal deployment solution would be to have an extra
James, your tone was unfortunate, but I do want do defend your
position *a little*.
Projects like ClojureScript (and CoffeeScript) -- and GWT and Vaadin
for that matter -- come from a certain anti-JavaScript attitude.
Though I sympathize, I would like to encourage all the JavaScript
haters to
plugin architecture is very incoherent. Try to design your
plugin and see!
On Jul 28, 9:40 pm, Praki Prakash praki.prak...@gmail.com wrote:
On Thu, Jul 28, 2011 at 5:20 PM, Tal Liron tal.li...@gmail.com wrote:
jQuery is not so much an elephant as it is a mammoth. It was one of
the first
You can also look at Prudence, which underneath uses Restlet:
http://threecrickets.com/prudence/
--
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
Hey folks,
I just want to reassure y'all that I am working on this. It took a while to
create a test environment: one of the challenges of using invokedynamic is
that the Java language does not support it; so the best way to test right
now is with ASM 4.0, which is still not officially
Since Ruby isn't designed to run on the JVM, it doesn't have
any syntax for type hints to avoid reflective calls. I believe method
calls that use invokedynamic are much faster than reflective
(non-hinted) method calls, but still a bit slower than type-hinted
calls. So if you are in a tight
Hmm... If you didn't have to worry about Java 7 compatibility, for one
thing with invokedynamic you could remove a lot of code from Clojure. No
more IFn or AFn. You simply have a method handle.
Actually, Clojure's solution is almost identical to a method handle. An
instance of AFn is not
Paul, I'm going to combine two posts of yours in to one, if I may, and
answer some of your points.
(Aaron, can we add some of this to the wiki, too? I'm including at least one
correction)
*-- For version 5 of the JVM, I agree, and if your goal is to maintain
compatibility with version 5 of
Another correction:
I stated that Clojure's maximum arity is 20. That's not exactly true: for
arity's beyond 20, IFn has a special invocation that accepts the arguments
as an array. But this means that the compiler has to account for this, and
arrange the arguments as a single array argument
Progress!
I am staring right now at my JVM 7 build of Clojure that uses invokedynamic
for Vars that contain functions. It essentially works, well enough for
experimentation. A few of my simple apps seem to work fine with it.
There are still a lot of problems: the Clojure test suite fails, and
Paul also points out areas where MethodHandles can replace the rather
sticky reflection work that Clojure does now to massage calls to non-Clojure
libraries. That's not entirely related to the invokedynamic stuff I'm
working on, so I think I'll leave it to somebody else to take a stab at
If you look at the links in my previous e-mail (specifically this one
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L1364).
The reflection is done in the compiler only when there is a tag (i.e. a type
hint). Otherwise the compiler just emits an invoke
Well, the statement you just made is true, but nonetheless you are the
one who is mistaken. The emit() method is called, but if not enough
information was present at compile time to resolve to a real method
call (that is, if `method = null` was executed), then the emit() code
emits a
Progress... is slow.
I encouraged other people to try, so the least I can do now is to point you
at some of the serious challenges.
Right now I have what I think is a nice semi-generic mechanism for
invokedynamic. It's called the Linker: it handles finding the target
method handle,
On 08/29/2011 06:01 PM, Aaron Bedra wrote:
The version of ASM that is bundled in Clojure is very old. This will
likely cause problems. You are correct in looking to ASM 4 since it has
started supported the JSR-292 stuff and other Java 7 changes. I am
planning on doing an
Jetty and Grizzly also work great, and can be used as easily swappable
connectors for Restlet, which in turn is used by Prudence's Clojure flavor
(I'm the lead developer):
http://threecrickets.com/prudence/
Jetty is the most mature of the bunch (Grizzly, Netty, MINA, etc.) and
offers many
On Wednesday, September 7, 2011 1:53:43 PM UTC-5, Marko Kocić wrote:
Thanks for the tip about jsvc. I'll give it a try. Do you have some script
examples to share, since having Linux service is exactly what I need?
I strongly recommend Tanuki's wrapper over jsvc:
On Tuesday, September 13, 2011 1:44:09 PM UTC-5, Sean Corfield wrote:
It was intended to be purely anecdotal but that doesn't seem to satisfy
anyone! :)
Homer: You know, when I was a boy, I really wanted a catcher's mitt, but my
dad wouldn't get it for me. So I held my breath until I passed
Wouldn't it be nice to add ClojureScript to this list:
http://repl.it/
Food for thought!
--
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 -
Scripturian is a scalable alternative to JSR-223, providing a clear
threading model for embedding JVM languages into high-concurrency
applications:
http://threecrickets.com/scripturian/
Note that this also brings Clojure 1.3.0 support to Prudence. It already
exists on trunk, and you can build
On Tuesday, September 27, 2011 1:57:03 PM UTC-5, Arthur Edelstein wrote:
So my request for Clojure's future development, is that backwards
compatibility not be broken. This means that Clojure code needs a way
of designating what Clojure version it is targeted for.
I'm with you, Arthur.
On Saturday, October 1, 2011 8:25:21 PM UTC-5, Andy Fingerhut wrote:
Tal, did you consider the possibility of staying with Clojure 1.2.1 and its
libraries? Or was that not under consideration for some reason?
It was a consideration, but the cons seemed to outweigh the pros.
Staying with
On Saturday, October 1, 2011 9:34:46 PM UTC-5, David Nolen wrote:
To give some context:
I appreciate the context, David, and I agree that the change needed to
happen. It's likely my fault for not being enough in the loop to realize
what the 1.3 change would mean for me. I expected some
On 10/01/2011 11:49 PM, Sean Corfield wrote:
I'm curious, what parts of contrib are you relying on that haven't
found active maintainers? Perhaps we can figure out how to address
that, to reduce your pain?
It's not that they weren't maintained. Well, I actually
On 10/02/2011 01:05 AM, Sean Corfield wrote:
Actually I think you're in a better position now. The
"new contrib"
libraries are all actively maintained and are expected to be
compatible with both Clojure 1.2.x and 1.3.0. I'm also hearing a
possibility that a
On Sunday, October 2, 2011 4:30:51 PM UTC-5, stuart@gmail.com wrote:
Modularity helps, not hurts, in achieving this.
I can see that now. Thanks to everyone who provided clarifications about the
new contrib organization!
Contrarily, it seems that effort is being put into cleaning up
On 10/02/2011 05:20 PM, Stuart Halloway wrote:
I was referring to the aggregate contrib, not a curated
subset (which I agree is a good idea). Maybe we should call the
aggregated thing the Libraries Formerly Known as Contrib
(LFKAC).
An excellent JVM library to use as base is Jackson:
http://jackson.codehaus.org/
It would be wonderful to see a Clojure-friendly version of it: having it
create Clojure-specific structures from JSON, and also recognizing Clojure
deftypes for serialization. The streaming API is friendly enough
Cheshire looks great, thanks for the tip!
I wonder, then, what's the OP's problem? I think it's good to have a
lightweight, 100% Clojure version of JSON in contrib. A lighter weight is
often a higher priority than performance. I think both approaches have their
place.
In the Java world, too,
As long as we're fixing d.c.json... it would be nice to add
support for encoding sequences and maps.
(I know, I should open a bug)
On 10/07/2011 02:04 PM, Sean Corfield wrote:
That would be http://dev.clojure.org/jira/browse/DJSON-1 which I
opened at
I'll plug Scripturian here, a library I wrote that has very good
thread-aware support for embedding Clojure, as well as other JVM languages
(JavaScript, Python, Ruby, PHP, Groovy):
http://threecrickets.com/scripturian/
I just recently wrote a detailed tutorial for it, which was missing for a
33 matches
Mail list logo
