On Thu, Aug 25, 2011 at 2:49 AM, Tal Liron wrote:
> 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
>
My company (read: I) develop an web-based educational application (a
language lab) implemented as a Java applet.
I have spendt the summer porting it to Clojure. I am very happy with
the results.
Except: The download (and therefore the download-time) has increased
dramatically, as I now include t
Hi,
There is a slim version of the clojure jar. See here for example here:
http://repo1.maven.org/maven2/org/clojure/clojure/1.3.0-beta1/
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@
The slim jar probably won't work in an applet, because it does classloader
stuff (unless you have a signed applet).
--
Dave
--
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
invokedynamic reduces drastically the lookup times you require in
dynamic languages. The JVM and JIT understand what you are trying
to do and can optimize the invocation.
Currently all dynamic languages targeting the JVM generate code
that cannot be easily optimized by the JVM before invokedynamic
I wrote a few examples up for explaining this:
http://blog.jayfields.com/2010/12/clojure-get-get-in-contains-and-some.html
they might be helpful if you want additional info above and beyond the docs.
Cheers, Jay
On Aug 24, 2011, at 5:15 PM, Mark Rathwell wrote:
> See the doc below. What (cont
That about sums it up. Specifically, I will talk about how some of
the Clojure features (fns, types, protocols, etc.) are emitted in
JavaScript and why one compiled form was chosen over any other (with
proper caveats for future change).
--
You received this message because you are subscribed to
Yes. My applet is signed. So that is not a problem.
Any thoughts about difference in performance between "slim" and
"full"?
My applet mostly does swing-stuff, http GETS and POSTS - and audio
playback and recording.
On 25 Aug, 10:40, David Powell wrote:
> The slim jar probably won't work in a
The runtime performance should be the same, but the startup time will be
slower because it will have to compile the clojure code at load time.
--
Dave
On 25 Aug 2011 12:15, "Terje Dahl" wrote:
> Yes. My applet is signed. So that is not a problem.
>
> Any thoughts about difference in performance
Hi,
Am Donnerstag, 25. August 2011 13:14:51 UTC+2 schrieb Terje Dahl:
> Any thoughts about difference in performance between "slim" and
> "full"?
>
The slim version has longer startup time, I presume. Otherwise there
shouldn't be a difference in performance.
Sincerely
Meikel
--
You recei
Ken:
Thanks for the answer. You're correct about distinct. I'm working through
some exercises.
cmn
--
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 mo
This does not really answer Ken's question, does it ?
2011/8/25 Paulo Pinto
> invokedynamic reduces drastically the lookup times you require in
> dynamic languages. The JVM and JIT understand what you are trying
> to do and can optimize the invocation.
>
> Currently all dynamic languages targeti
Hi,
Disclaimer: I have no clue whatsoever about the low-level JVM stuff.
I remember Rich saying in one of his talks/interviews, that invokedynamic is
not very interesting for Clojure and that Clojure won't really benefit from
it. I'm far from understanding these things. So details on what's imp
Does anyone have a deftrace sample handy? I'm getting
Caused by: clojure.lang.Compiler$CompilerException: java.lang.Exception:
Unable to resolve symbol: deftrace in this context (repl_test.clj:15)
in
(ns repl-test
(:gen-class)
(:use clojure.contrib.command-line)
(:require [clojure.contr
That's correct. That is why Clojure/core hasn't prioritized this work.
Cheers,
Aaron Bedra
--
Clojure/core
http://clojure.com
On 08/25/2011 08:37 AM, Meikel Brandmeyer (kotarak) wrote:
Hi,
Disclaimer: I have no clue whatsoever about the low-level JVM stuff.
I remember Rich saying in one of
Forgot about doing this:
(:require [clojure.contrib.trace :as ctr])
cmn
--
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 patien
Please search through previous messages/tickets before posting new
issues. This issue has been fixed as of commit da412909d36551a526ed and
will be included in the -beta2 release. It was originally ticketed here:
http://dev.clojure.org/jira/browse/CLJ-816
(let [m (into {} (for [x (range 1
> My company (read: I) develop an web-based educational application (a
> language lab) implemented as a Java applet.
>
> I have spendt the summer porting it to Clojure. I am very happy with
> the results.
>
> Except: The download (and therefore the download-time) has increased
> dramatically, as
Hey,
Has there been discussion about making clojure.lang.IDeref a protocol?
I'd like to extend some java types to this the IDeref interface but
currently this is not possible. I feel like this is such a common
idiom, to get values, and doing so will allow me to leverage the @
reader macro for many
Ok after two days I manage to write framework for publishing and
calling webservices (yesterday I asked you for such framework but only
RESTful are available). Right now this implementation supports only
primitve types and was tested in Java distributed environment (needs
to extend to arrays, maps,
> Hey,
>
> Has there been discussion about making clojure.lang.IDeref a protocol?
> I'd like to extend some java types to this the IDeref interface but
> currently this is not possible. I feel like this is such a common
> idiom, to get values, and doing so will allow me to leverage the @
> reader
One of the first things that I want to know how to do when I learn a
new programming language is how to read from or print to a file. The
problem is that none of the clojure books do a good job of explaining
how to do so, in my opinion. What little is said is usually tucked
away and not highlight
I too stumbled upon this a while ago. I might even say that on some
level it's so simple that there is not much documentation about it, and
at some point it gets 'complex' enough that you should know about java
enough.
The simplest way is to slurp or spit. slurp reads a file into a string,
and spi
On Thu, Aug 25, 2011 at 5:18 AM, Paulo Pinto wrote:
> invokedynamic reduces drastically the lookup times you require in
> dynamic languages. The JVM and JIT understand what you are trying
> to do and can optimize the invocation.
It's important to note that this only applies to method calls, not
f
I did, of course. I searched for "transient", and didn't find any
describing this issue. And looking at the issue you link to, I still
don't see how it's related: it's a patch specifically for vectors, and
this code doesn't touch vectors; and it involves changes to a
transient "leaking" back into t
Update: just built master, and issue still exists. If you want to be
"sure" you get it, just add another zero to the input range. I'll
mention that in the ticket as well.
On Aug 25, 10:14 am, Alan Malloy wrote:
> I did, of course. I searched for "transient", and didn't find any
> describing this
Great question. And great answer.
Seriously! I did not know it could be that easy.
So an http GET just needs 1 lines!:
(slurp (reader "http://google.com";))
(Don't forget: (use 'clojure.java.io) )
Is there an equally easy way to do an http POST?
And also a multi-part (including one or mor
For that you'll have to look into the clj-http library:
https://github.com/mmcgrana/clj-http
>From the readme: (client/post "http://site.com/resources"; {:body "string"})
On Thu, Aug 25, 2011 at 2:00 PM, Terje Dahl wrote:
> Great question. And great answer.
> Seriously! I did not know it coul
@Aaron: Could you go into why this is the case? What does jruby do
that it needs it so much and clojure does not.
@Tal Liron: You seem to differ in your opinion with Aaron (pretty sure
you would not be investing your time otherwise). What exactlly are you
attempting to speed up and how does invoke
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.
Second, I think it would allow the JVM to have a better view into
optimization, and would allow the
On Thu, Aug 25, 2011 at 2:35 PM, Paul Stadig wrote:
> I think invokedynamic would be great for Clojure. Of course there are other
> concerns like the fact that it is only for Java 7, so maybe it won't be the
> best place to put resources at the moment. But that's no reason that Tal
> can't work on
On 25 Ago, 20:21, Nick Zbinden wrote:
> @Aaron: Could you go into why this is the case? What does jruby do
> that it needs it so much and clojure does not.
>
> @Tal Liron: You seem to differ in your opinion with Aaron (pretty sure
> you would not be investing your time otherwise). What exactlly ar
Right invokedynamic doesn't just "mostly benefit object-oriented languages."
A MethodHandle can be used for anything that the JVM can do from a static
method call, to an instance method call, to a constructor, to a field
access.
And in fact the bootstrap method that links an invokedynamic call
This gives several I/O examples:
http://nakkaya.com/2010/06/15/clojure-io-cookbook/
--
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 b
A significant speed improvement without resorting to type hints would be a
pretty huge win from a programmer's standpoint.
Kenny
On Thu, Aug 25, 2011 at 1:21 PM, Nick Zbinden wrote:
> @Aaron: Could you go into why this is the case? What does jruby do
> that it needs it so much and clojure does
On Thu, Aug 25, 2011 at 7:53 AM, octopusgrabbus
wrote:
> Ken:
>
> Thanks for the answer.
You're welcome.
> You're correct about distinct. I'm working through some exercises.
Ah. Always good to get to know the language better.
--
Protege: What is this seething mass of parentheses?!
Master: You
On Thu, Aug 25, 2011 at 11:40 AM, Stuart Halloway
wrote:
>> Has there been discussion about making clojure.lang.IDeref a protocol?
>
> Someday. The challenge is load order. A lot would have to change to make
> protocols available early enough in Clojure's bootstrap to allow this.
Thinking outside
We've been experimenting with ClojureScript and D3, a JavaScript DOM-
manipulation with an emphasis on data visualization, and we just put
our work on the Github:
https://github.com/lynaghk/cljs-d3/
Basically, this is a façade that proxies the native D3 JavaScript
functions so that you don't
It's hanging here too, but I have no idea why; I'm not including swank.
Is there any "verbose mode" for lein?
--
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 membe
So, after setting up a JVM 7 environment to play with Clojure, and
enthusiastically rummaging through the codebase, I have good news and bad
news. :)
(To quickly answer someone's question here -- I do know that it's a low
priority for the Clojure project, but thought the potential benefit could
>
> 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 t
> I think part of the reason for
> this is the conception (maybe misconception) that most people are
> familiar with java and since there is java interopt they should be
> able to figure this out. As more and more schools are starting to use
> Python as their beginning CS language, this may well n
> A significant speed improvement without resorting to type hints would be a
> pretty huge win from a programmer's standpoint.
True, but this is not a problem that invokedynamic can solve. :) It would
require, perhaps, better automation in the decision of how to coerce types
when calling J
> 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
Very cool! I was actually implemented a little visualization lib
inspired by D3 directly in cljs. I'll clean it up and push it to
http://github.com/ibdknox/pinot tonight.
D3 is awesome, so I'm excited to see stuff like this. :)
Cheers,
Chris.
On Aug 25, 4:42 pm, Kevin Lynagh wrote:
> We've been
On Aug 25, 2011, at 2:00 PM, Terje Dahl wrote:
> Great question. And great answer.
> Seriously! I did not know it could be that easy.
Unfortunately it's not actually that easy, at least for the OP's question of
reading from and writing to (presumably local) files.
While slurp and spit are be
Rad!
I used Compojure last time I did web development in Clojure, but since
I've been picking up ClojureScript I've also been using Pinot + Noir---
nice job on those guys. If you're going to the Conj, you'll have to
track me down so I can buy you a drink.
kevin
On Aug 25, 3:44 pm, Chris Granger
Note that most of those examples look a little dated and would benefit from
a heapin' helpin' of clojure.java.io and friends. For instance, slurp is
quite happy to read from a java.net.URL so fetch-url is unnecessary.
Unfortunately slurp is a little under documented.
Dave
On Thursday, August 25,
On Thu, Aug 25, 2011 at 6:49 PM, Lee Spector wrote:
> While slurp and spit are beautifully elegant it's not so elegant to tell
> slurp how to find the file you want it to slurp. In many other
> languages/environments there's a concept of the working directory or project
> directory, relative to
> That said, I don't know many Java classes that have value-yielding semantics.
> And if you are writing your own class, you can implement the IDeref interface.
There aren't many value-yielding semantics from many java classes, but
the ones I care about, do matter. Also, in my case, I'm adding v
On Aug 25, 2011, at 9:27 PM, Ken Wesson wrote:
> On Thu, Aug 25, 2011 at 6:49 PM, Lee Spector wrote:
>> While slurp and spit are beautifully elegant it's not so elegant to tell
>> slurp how to find the file you want it to slurp. In many other
>> languages/environments there's a concept of the
On Thu, Aug 25, 2011 at 11:19 PM, Lee Spector wrote:
>
> On Aug 25, 2011, at 9:27 PM, Ken Wesson wrote:
>
>> On Thu, Aug 25, 2011 at 6:49 PM, Lee Spector wrote:
>>> While slurp and spit are beautifully elegant it's not so elegant to tell
>>> slurp how to find the file you want it to slurp. In ma
52 matches
Mail list logo
