Re: defmatch macro
Cool, if only that macro could expand to function which detects in runtime if one of argument which being matched is seq or vec and call proper routine which is applying :seq or leaving matching expression as for random access. This is just higher level automation, it doesn't breake core functionality, it is slower by the only one check and it would be slower by explicite use of that macro. -- 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
clojure.core.logic.core/match usage
Hello everybody,
I was playing with core.match library and I notice the following behavior
let [x {:a 1 :b 2 :c 10 :d 30}]
(match [x]
[({:a _ :b _ :c _ :d _} :only [:a :b :c :d])] :a-1
[({:a _ :b 2} :only [:a :b])] :a0
[{:a 1 :c _}] :a1
[{:c 3 :d _ :e 4}] :a2
:else []))
returns
:a1
I was hoping to get
:a-1
Am I using it wrong? Have I misunderstood as to how match is supposed to
work? It looks like match assumes either that there is always a unique match
or it does not guarantee that it will the try matches in the order
specified. Can somebody help?
Thanks,
Sunil.
--
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
Re: clojure.core.logic.core/match usage
please excuse the mistake in the namespace in the subject line... it should
have been
clojure.core.match.core/match
On Mon, Oct 3, 2011 at 3:57 PM, Sunil S Nandihalli
sunil.nandiha...@gmail.com wrote:
Hello everybody,
I was playing with core.match library and I notice the following behavior
let [x {:a 1 :b 2 :c 10 :d 30}]
(match [x]
[({:a _ :b _ :c _ :d _} :only [:a :b :c :d])] :a-1
[({:a _ :b 2} :only [:a :b])] :a0
[{:a 1 :c _}] :a1
[{:c 3 :d _ :e 4}] :a2
:else []))
returns
:a1
I was hoping to get
:a-1
Am I using it wrong? Have I misunderstood as to how match is supposed to
work? It looks like match assumes either that there is always a unique match
or it does not guarantee that it will the try matches in the order
specified. Can somebody help?
Thanks,
Sunil.
--
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
Re: clojure.core.logic.core/match usage
If I remove the line [{:a 1 :c _}] :a1 it returns :a-1 .. So, I guess it
means that the behavior is undefined if there are multiple matches.
Sunil.
On Mon, Oct 3, 2011 at 3:57 PM, Sunil S Nandihalli
sunil.nandiha...@gmail.com wrote:
Hello everybody,
I was playing with core.match library and I notice the following behavior
let [x {:a 1 :b 2 :c 10 :d 30}]
(match [x]
[({:a _ :b _ :c _ :d _} :only [:a :b :c :d])] :a-1
[({:a _ :b 2} :only [:a :b])] :a0
[{:a 1 :c _}] :a1
[{:c 3 :d _ :e 4}] :a2
:else []))
returns
:a1
I was hoping to get
:a-1
Am I using it wrong? Have I misunderstood as to how match is supposed to
work? It looks like match assumes either that there is always a unique match
or it does not guarantee that it will the try matches in the order
specified. Can somebody help?
Thanks,
Sunil.
--
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
Re: producing Blub code and vv.
Hi, Well many will agree that if you can find a good solution to this problem this is going to be usefull. I tend to agree too. The question is maybe can you find a good solution? My response would be no. Let me explain: From a theoretical point of view you can always translate one turring complete language to one another; But if you do that you really miss the point of using clojure instead of blurb. Clojure isn't theorycally better. It is not. Every thing you can do in clojure you'll be able to do in any blurb language, at soon at it is turing complete. So this include cobol, vhdl or SQL. If it was easy to transform easilly back and forth to idiomatic blurb language that would mean that there is some sort of bijection between all idiomatic feature of clojure and blurb. But the whole point of using clojure instead of blurb here is because clojure is a better or at least different language. With more interresting abstractions than one available in blurb, at least for a specific problem domain. So the bijection is not here. To have this bijection the blurb language would need to be clojure with a different syntax. We could think about common lisp but even there... Immutability and persistent collection could be enough to make the translation not idiomatic at all. And this only for the language. A language is just one part of the problem. You also need the libraries. For example GWT team had to support a good subset of Java API to make GWT usable. To transform back and forth would mean that you'll need a common API for both language, that is an API that would not be idiomatic for at least one of thoses language. More than being not idiomatic this would be an API thoses of blurb would not be used to. Maybe all of this is possible. After all an human can do it manually. But I see it as more a research topic than engineering topic. With low probability of sucess. It is a good thing to work on it then when many things aren't here yet for clojure? Best Regards, Nicolas. On Sep 30, 5:48 am, Hank h...@123mail.org wrote: I think the major obstacle is likely to be the difference in idioms. Any substantial idiomatic piece of Clojure is going to be almost impossible to automatically translate to _idiomatic_ code in another high-level language that uses different idioms. That could very well turn out to be the case. In the spectrum between fully manual and fully automated I can picture scenarios like: - Mostly manual but with some automatic assistance from the IDE: E.g. the way Eclipse assists you in coding Java, when you press Ctrl+Space. It doesn't automatically write code for you but it can narrow down the choice as to what to type next. - Most automatic but with some manual assistance from the coder: E.g. annotate the Clojure code with hints about the idioms to translate to in the target language. Right now in Clojure we use annotations like :exposes-methods that aren't strictly for the Clojure functionality itself but for Java interop. So there could be annotations like :use-design-pattern-x that dictate the choice of idiom/design pattern in the compilation to the target language. You'd also probably have to introduce a number of coding conventions to constrain your Clojure code in order to avoid holes in the translation. It's probably a question of how unwieldy the produced code is allowed to get. If you express the goal of maintainability in terms of some metric like lines of code or whatever then I can see hard limits being reached. If you don't put a limit on that then I don't see any danger of holes. Some questions: * How do you translate Clojure functions in namespaces spread across multiple files into a Java class? [...] Those are very good questions and I'd have to think about it. Maybe I'll start a wiki somewhere so we can start collecting translation recipes. Generally, if the answer isn't obvious from staring at the Clojure code, it helps to think about the problems in terms of the bigger picture, i.e. the business logic/domain knowledge, and then translate to Blub in the head. E.g. I want to cache generated web pages on the disk, how would I do this in Java? * How would code that uses STM translate to a Blub without it? I like this one in particular. People have written concurrent code before STM. I do it in my job every day. :) How did that work with explicit locks again?? * How idiomatic would Blub code be when Clojure uses immutable data by default? A good source for this is the O'Reilly book Functional Programming in Java. There you can see how idioms from one language can be applied to another. I think Java code that uses a lot of immutable data, i.e. final variables all around, would still be accepted by the Java community. The produced code could even leave out the final keyword in order to not cause too much clutter but still not modify the variables. It violates the principle of least authority but I see
Re: clojure.core.logic.core/match usage
I *think* this is because when there are multiple matches, the most
specialized matches and 1 is less generic than _
On Mon, Oct 3, 2011 at 12.39 PM, Sunil S Nandihalli
sunil.nandiha...@gmail.com wrote:
If I remove the line [{:a 1 :c _}] :a1 it returns :a-1 .. So, I guess it
means that the behavior is undefined if there are multiple matches.
Sunil.
On Mon, Oct 3, 2011 at 3:57 PM, Sunil S Nandihalli
sunil.nandiha...@gmail.com wrote:
Hello everybody,
I was playing with core.match library and I notice the
following behavior
let [x {:a 1 :b 2 :c 10 :d 30}]
(match [x]
[({:a _ :b _ :c _ :d _} :only [:a :b :c :d])] :a-1
[({:a _ :b 2} :only [:a :b])] :a0
[{:a 1 :c _}] :a1
[{:c 3 :d _ :e 4}] :a2
:else []))
returns
:a1
I was hoping to get
:a-1
Am I using it wrong? Have I misunderstood as to how match is supposed to
work? It looks like match assumes either that there is always a unique match
or it does not guarantee that it will the try matches in the order
specified. Can somebody help?
Thanks,
Sunil.
--
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 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
Re: clojure.core.logic.core/match usage
It's a bug, thanks for the report,
http://dev.clojure.org/jira/browse/MATCH-23
David
On Mon, Oct 3, 2011 at 6:27 AM, Sunil S Nandihalli
sunil.nandiha...@gmail.com wrote:
Hello everybody,
I was playing with core.match library and I notice the following behavior
let [x {:a 1 :b 2 :c 10 :d 30}]
(match [x]
[({:a _ :b _ :c _ :d _} :only [:a :b :c :d])] :a-1
[({:a _ :b 2} :only [:a :b])] :a0
[{:a 1 :c _}] :a1
[{:c 3 :d _ :e 4}] :a2
:else []))
returns
:a1
I was hoping to get
:a-1
Am I using it wrong? Have I misunderstood as to how match is supposed to
work? It looks like match assumes either that there is always a unique match
or it does not guarantee that it will the try matches in the order
specified. Can somebody help?
Thanks,
Sunil.
--
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 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
Re: suggestion for clojure development
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). Here's how I envision the distribution structure: Clojure Core: the language engine itself, at its bare minimum Clojure Base: a collection of crucial libraries that is released *in tandem* with Clojure Core, meaning that they have the same base version which they are tested against. So, Clojure 1.5 would be released at the same time as Clojure Base 1.5. Critical fixes could then be minor releases, such as Clojure Base 1.5.1. But, it would be obvious that it is tested against Clojure 1.5.X and that is *for* Clojure 1.5.X. The Clojure Base libraries would also exist on their own with their own versions, and can be upgraded or used separately. The Clojure Base versioned distribution establishes a integrally tested baseline: the idea is that if you stick to Clojure Base, you cannot go wrong, and a clear upgrade path would appear in the future if necessary, say, for 1.6. Clojure Extras: community-maintained libraries outside of Clojure Base, but that are -- for convenience's sake -- listed on Clojure's main web sites and repositories next to the Clojure Base libraries. What marks these libraries as different from just any other library in the larger Clojure ecosystem is that Clojure Extras get approved clojure.* namespaces, such as clojure.java.jdbc. Some of these might be candidates for eventual inclusion in Clojure Base (marked as incubating) but they do not have to be; Clojure Extras might be their natural home. For inclusion in Clojure Extras, a library would have to prove some kind of essential generic functionality warranting a clojure.* namespace, such as support for a standard or technology or an implementation of a well-known algorithm. So: no frameworks, products, etc. The idea is that users would go to Clojure Extras first to find an API, knowing that it has received some minimal review, before rummaging through the wild, wild Internets. The batteries included build at http://dev.clojure.org/display/design/Release.Next+Planning is probably the same as your Clojure Base. Stu Stuart Halloway Clojure/core http://clojure.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
Re: Equality comparison in 1.3
core.clj currently contains two definitions of =, one of which is commented out. The active one has this docstring: Equality. Returns true if x equals y, false if not. Same as Java x.equals(y) except it also works for nil, and compares numbers and collections in a type-independent manner. Clojure's immutable data structures define equals() (and thus =) as a value, not an identity, comparison. and the commented-out one has this: Equality. Returns true if x equals y, false if not. Same as Java x.equals(y) except it also works for nil. Boxed numbers must have same type. Clojure's immutable data structures define equals() (and thus =) as a value, not an identity, comparison. Sounds to me like the second one was intended to be the new docstring. - Chris -- 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
Re: producing Blub code and vv.
Thanks for writing, I think this here sums it up nicely: Maybe all of this is possible. After all an human can do it manually. I have a background in machine learning/artificial intelligence ... and yes I can see those things come in handy here. But I see it as more a research topic than engineering topic. With low probability of sucess. Well, some people are enticed by research and high risk. :) -- 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
ClojureScript REPL Changes
Several improvements have been made to the ClojureScript REPL. In ClojureScript, the method of printing output will be different for each evaluation environment. There is now a var named *print-fn* in cljs.core which will need to be explicitly set to a function that can print in the target environment. If you would like to ignore all printed output you could do this: (set! *print-fn* (constantly nil)) The print function that you specify takes one argument, the value to be printed. What you do with that value is totally up to you and your environment. Sane defaults are set when running the REPL with Rhino or the browser. We are now using Rhino version 1.7R3 instead of whatever version of Rhino is bundled with Java. This provides the following benefits: * better error messages * nice JavaScript stacktraces * it's faster * it isn't tied to a particular VM (should fix the problems people were seeing on OpenJDK) You will need to rerun script/bootstrap to download the Rhino jar and install it in your lib folder. Windows people will need to do this manually. http://www.mozilla.org/rhino/download.html For the browser-connected REPL, we can now print to the REPL. This means that the browser-connected REPL works exactly like an old- fashioned Clojure REPL. For example, you can now do this: ClojureScript:cljs.user (time (reduce + (range 1000))) Elapsed time: 222 msecs 499500 If your application is printing things while running then this printed output will be printed in the REPL. Of course, you can set the *print- fn* to do whatever you like. Finally, when using Chrome and Firefox for evaluation, you will now see JavaScript stacktraces in the REPL. If you have been using the browser-connected REPL then you will need to delete the .repl folder before using the new changes. -- 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
Re: Problem Running ClojureScript on OpenJDK
If you have been having problems the ClojureScript and OpenJDK, please
try the current master branch of ClojureScript.
I would be interested to know what problems still remain, if any,
after these changes.
On Oct 2, 11:07 pm, db donald.bl...@gmail.com wrote:
Here's what the patch looks like for openjdk-6 with the latest master,
where the mozilla-specific lines have moved to the rhino.js file:
diff --git a/src/clj/cljs/repl/rhino.clj b/src/clj/cljs/repl/rhino.clj
index cbe4f2a..15c5bf1 100644
--- a/src/clj/cljs/repl/rhino.clj
+++ b/src/clj/cljs/repl/rhino.clj
@@ -27,6 +27,7 @@ goog.require = function(rule)
{Packages.clojure.lang.RT[\var\
linenum (or line Integer/MIN_VALUE)
ctx (sun.org.mozilla.javascript.Context/enter)]
(try
+ (.setOptimizationLevel ctx -1)
{:status :success
:value (.evaluateString ctx (:global repl-env) js filename
linenum nil
(finally
This works for me on openjdk6, but will not work on openjdk7 because
it doesn't ship with Rhino. For openjdk7, it looks like a separate
version of Rhino needs to be downloaded.
On Oct 2, 4:36 pm, Stefan Kamphausen ska2...@googlemail.com wrote:
Hi,
I hope, people are aware that Oracle considers OpenJDK to be the standard
choice for Linux users now and removed the special distributor's license.
Seehttp://robilad.livejournal.com/90792.html
Kind regards,
Stefan
--
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
Re: ClojureScript REPL Changes
I've been playing with the changes for the past few days. Huge improvement. Thanks for all this! David On Mon, Oct 3, 2011 at 10:11 AM, Brenton bashw...@gmail.com wrote: Several improvements have been made to the ClojureScript REPL. In ClojureScript, the method of printing output will be different for each evaluation environment. There is now a var named *print-fn* in cljs.core which will need to be explicitly set to a function that can print in the target environment. If you would like to ignore all printed output you could do this: (set! *print-fn* (constantly nil)) The print function that you specify takes one argument, the value to be printed. What you do with that value is totally up to you and your environment. Sane defaults are set when running the REPL with Rhino or the browser. We are now using Rhino version 1.7R3 instead of whatever version of Rhino is bundled with Java. This provides the following benefits: * better error messages * nice JavaScript stacktraces * it's faster * it isn't tied to a particular VM (should fix the problems people were seeing on OpenJDK) You will need to rerun script/bootstrap to download the Rhino jar and install it in your lib folder. Windows people will need to do this manually. http://www.mozilla.org/rhino/download.html For the browser-connected REPL, we can now print to the REPL. This means that the browser-connected REPL works exactly like an old- fashioned Clojure REPL. For example, you can now do this: ClojureScript:cljs.user (time (reduce + (range 1000))) Elapsed time: 222 msecs 499500 If your application is printing things while running then this printed output will be printed in the REPL. Of course, you can set the *print- fn* to do whatever you like. Finally, when using Chrome and Firefox for evaluation, you will now see JavaScript stacktraces in the REPL. If you have been using the browser-connected REPL then you will need to delete the .repl folder before using the new changes. -- 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 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
Re: strangeloop presentations
N!! 2011/10/2 Alex Miller a...@puredanger.com Phil's was a 3 hour workshop and was not recorded sorry. On Oct 2, 4:01 am, Andreas Liljeqvist bon...@gmail.com wrote: Actually I am mostly looking forward to Phil's Getting Cozy with Emacs. I am very disappointed that there aren't more buzz about it. Come on people - it's about Emacs! -- 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 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
Can't eval locals problem
Ok, so I'm stuck. If any of you more seasoned clojurians have a hint that could get me out, I will be forever gratefull to him/her: I'm trying execute a query against google app engine datastore, using appengine-magic, with the filter dynamically generated from a map. Here's the closest code I have been able to come up with: (defmacro order-query [params] `(ds/query :kind Order :filter ~(map #(list (key %) (val %)) (eval params This macro fails with a Can't eval locals error. I recognize that the main issue here is that i'm forcing evaluation of something at macro expansion time. Apparently clojure does not (fully) support this, so I'm looking then for alternatives. Cheers, Razvan -- 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
Re: break-on-gaps - just curious if there is a more idiomatic way to do this
qhfgva, 2011-09-28 20:39 +0200 I was wondering if there is a more clever/idiomatic way to solve this problem. (defn break-on-gaps [minutes] (reduce (fn [acc x] (if (empty? acc) [[x]] (if (= (inc (last (last acc))) x) (conj (vec (butlast acc)) (conj (last acc) x)) (conj acc [x] [] minutes)) user= (break-on-gaps [1 2 3 5 6 7 8 10 20 21]) [[1 2 3] [5 6 7 8] [10] [20 21]] Instead of folding from left with reduce you might consider the pros and cons of folding from right with (defn foldr [f f0 s] (if (empty? s) f0 (f (first s) (foldr f f0 (rest s) then (defn break-on-gaps [minutes] (foldr (fn [x acc] (if (= (inc x) (ffirst acc)) (cons (cons x (first acc)) (rest acc)) (cons (cons x ()) acc))) () minutes)) -- Take it Easy Don't HurryBe Happy Thierry °°şo§oş°°şo§oş°°şo§oş°°şo§oş°°şo§oş°° -- 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
Re: Can't eval locals problem
Try (defmacro order-query [params] `(ds/query :kind Order :filter (map #(list (key %) (val %)) ~params))) or (defmacro order-query [params] `(ds/query :kind Order :filter (map #(list (key %) (val %)) (eval ~params depending on the necessity of the eval (I suppose you don't really need the eval... the problem was using the eval in the evaluation of a macro I guess... ;)). 2011/10/3 Razvan Rotaru razvan.rot...@gmail.com Ok, so I'm stuck. If any of you more seasoned clojurians have a hint that could get me out, I will be forever gratefull to him/her: I'm trying execute a query against google app engine datastore, using appengine-magic, with the filter dynamically generated from a map. Here's the closest code I have been able to come up with: (defmacro order-query [params] `(ds/query :kind Order :filter ~(map #(list (key %) (val %)) (eval params This macro fails with a Can't eval locals error. I recognize that the main issue here is that i'm forcing evaluation of something at macro expansion time. Apparently clojure does not (fully) support this, so I'm looking then for alternatives. Cheers, Razvan -- 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 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
Re: Can't eval locals problem
Ok, so I'm stuck. If any of you more seasoned clojurians have a hint that could get me out, I will be forever gratefull to him/her: I'm trying execute a query against google app engine datastore, using appengine-magic, with the filter dynamically generated from a map. Here's the closest code I have been able to come up with: (defmacro order-query [params] `(ds/query :kind Order :filter ~(map #(list (key %) (val %)) (eval params This macro fails with a Can't eval locals error. I recognize that the main issue here is that i'm forcing evaluation of something at macro expansion time. Apparently clojure does not (fully) support this, so I'm looking then for alternatives. Cheers, Razvan Hi Razvan, Can you tell us a bit more: (1) the stack trace of the error you are seeing (2) the form you are using to call order-query (3) what you expect evaling something at macroexpansion time should be doing Thanks, Stu -- 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
Exception handling changes in Clojure 1.3.0
I ran into an interesting problem while porting appengine-magic to Clojure 1.3.0. The Google App Engine SDK uses checked exceptions on many of its API methods. In many cases, I want to catch these exceptions and do something Clojure-friendly with them. With Clojure 1.2.x, I had no trouble catching checked exceptions by type, e.g.: (try (some-app-engine-api-methods-called-here ...) (catch EntityNotFoundException ex ...)) This stopped working in 1.3.0. The caught exception does not match EntityNotFoundException; it is now a RuntimeException with the original typed exception chained to it. I don't fully understand the implications of the exception handling changes in 1.3 (https://github.com/clojure/clojure/commit/ 8fda34e4c77cac079b711da59d5fe49b74605553). Does it mean that all exceptions coming in from Java code into Clojure will now be wrapped in an extra RuntimeException? If so, then typed catch clauses become useless, and the equivalent functionality will require writing code like this: (catch Exception ex (cond (isa? (class (.getCause ex)) EntityNotFoundException) ...)) I can wrap that in some kind of a catch* macro (which would also support directly catching an exception for Clojure 1.2.x compatibility), but I'm wondering if I'm doing something wrong here. -- 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
Re: Exception handling changes in Clojure 1.3.0
The Google App Engine SDK uses checked exceptions on many of its API methods. In many cases, I want to catch these exceptions and do something Clojure-friendly with them. With Clojure 1.2.x, I had no trouble catching checked exceptions by type, e.g.: (try (some-app-engine-api-methods-called-here ...) (catch EntityNotFoundException ex ...)) This stopped working in 1.3.0. The caught exception does not match EntityNotFoundException; it is now a RuntimeException with the original typed exception chained to it. I don't fully understand the implications of the exception handling changes in 1.3 (https://github.com/clojure/clojure/commit/ 8fda34e4c77cac079b711da59d5fe49b74605553). Does it mean that all exceptions coming in from Java code into Clojure will now be wrapped in an extra RuntimeException? Catching checked exceptions seems to work fine. Try e.g. (try (throw (java.io.IOException.)) (catch java.io.IOException _ caught!)) I suspect something else is going wrong in the GAE example. Can you narrow the code down to a block you can quote in full here? Stu Stuart Halloway Clojure/core http://clojure.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
Re: Exception handling changes in Clojure 1.3.0
Reflector.java wraps checked exceptions in runtime exceptions On Mon, Oct 3, 2011 at 12:27 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: The Google App Engine SDK uses checked exceptions on many of its API methods. In many cases, I want to catch these exceptions and do something Clojure-friendly with them. With Clojure 1.2.x, I had no trouble catching checked exceptions by type, e.g.: (try (some-app-engine-api-methods-called-here ...) (catch EntityNotFoundException ex ...)) This stopped working in 1.3.0. The caught exception does not match EntityNotFoundException; it is now a RuntimeException with the original typed exception chained to it. I don't fully understand the implications of the exception handling changes in 1.3 (https://github.com/clojure/clojure/commit/ 8fda34e4c77cac079b711da59d5fe49b74605553). Does it mean that all exceptions coming in from Java code into Clojure will now be wrapped in an extra RuntimeException? Catching checked exceptions seems to work fine. Try e.g. (try (throw (java.io.IOException.)) (catch java.io.IOException _ caught!)) I suspect something else is going wrong in the GAE example. Can you narrow the code down to a block you can quote in full here? Stu Stuart Halloway Clojure/core http://clojure.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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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
Re: Can't eval locals problem
eval does work at macro expansion time, but only where it is actually possible to evaluate the expression its given with only the information available at macro expansion time at hand. One case where there is not enough information -- and a minimal Can't eval locals example -- is the following: (defmacro foo [x] (eval x)) (let [y 1] (foo y)) Are you doing something similar...? eval's behaviour here is very sensible, since it is asked to eval the Symbol y at compile time, when it knows that it names a local binding, but does not know what the value of that local binding is going to be at runtime. (It could conceivably notice that this particular local is given a constant initializer expression, but that would only raise expectations for cases like (let [y (some-function)] (foo y)) where using the compile-time return value of (some-function) would make no sense even if it were possible to obtain it.) That doesn't mean eval'ing stuff at compile time is not possible, it's just that one has to make sure that one is eval'ing forms which have meaningful compile-time values. Sincerely, Michał PS. Actually it's fun to go code diving to see how this breaks exactly... Although it's not terribly helpful in writing code. A summary of the code path this goes through is, I think, that clojure.core/eval delegates to clojure.lang.Compiler.eval, which in turn needs the expression analysed by clojure.lang.Compiler.analyze, which in this case delegates to clojure.lang.Compiler.analyzeSymbol, which in this case -- called at compile-time inside this particular let form -- finds a binding for the Symbol y included in the local environment and accordingly returns a LocalBindingExpr, which is something un-eval-able. -- 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
Re: Exception handling changes in Clojure 1.3.0
I believe the actual problem comes from things like RT.classForName(), which internally catches a ClassNotFoundException, and then does this: throw Util.runtimeException(e); That ends up just sort of obscuring what the exception is, and you can't just catch ClassNotFoundException - you have to catch the RuntimeException, and then figure out what it really means if you actually have to respond to a specific case. I'm not a particular fan of checked exceptions, but I don't entirely understand the rationale behind this. On Oct 3, 12:27 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: The Google App Engine SDK uses checked exceptions on many of its API methods. In many cases, I want to catch these exceptions and do something Clojure-friendly with them. With Clojure 1.2.x, I had no trouble catching checked exceptions by type, e.g.: (try (some-app-engine-api-methods-called-here ...) (catch EntityNotFoundException ex ...)) This stopped working in 1.3.0. The caught exception does not match EntityNotFoundException; it is now a RuntimeException with the original typed exception chained to it. I don't fully understand the implications of the exception handling changes in 1.3 (https://github.com/clojure/clojure/commit/ 8fda34e4c77cac079b711da59d5fe49b74605553). Does it mean that all exceptions coming in from Java code into Clojure will now be wrapped in an extra RuntimeException? Catching checked exceptions seems to work fine. Try e.g. (try (throw (java.io.IOException.)) (catch java.io.IOException _ caught!)) I suspect something else is going wrong in the GAE example. Can you narrow the code down to a block you can quote in full here? Stu Stuart Halloway Clojure/corehttp://clojure.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
Re: ANN: tools.trace 0.7.1
Luc Prefontaine lprefonta...@softaddicts.ca writes: [...] Just add: [org.clojure/tools.trace 0.7.1] to your dependency list in your project.clj. This should be a straight replacement for clojure.contrib.trace in your code. If you find suggestions/improvements it's time to let me know about them. Src code and README at: https://github.com/clojure/tools.trace It seems that instead of #Usage: (ns your-namespace (:require tools.trace)) it should be: #Usage: (ns your-namespace (:require clojure.tools.trace)) Br, Rob -- 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
Re: Can't eval locals problem
Ok, so I mailed off the above discussion without including any suggestions for alternative approaches... *fail* Anyway, I think Joop's answer (especially the first code snippet) is *very* likely to be the best. As far as I can tell from reading the source, appengine-magic's query macro includes the filter expression in its expansion verbatim, so it will just be evaluated at run time. If you do want to play around with some super-flexible eval-based approaches, you might want to give Michael Fogus's highly enjoyable evalive library [1] a try -- it provides an aptly named #'evil function which, together with its companion macro #'local-bindings (or was it #'local-env...), does allow one more flexibility in what one evals. The usual warnings (don't eval unless you have to etc.) apply. Sincerely, Michał [1] https://github.com/fogus/evalive -- 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
Re: Exception handling changes in Clojure 1.3.0
On Mon, Oct 3, 2011 at 12:03 PM, Constantine Vetoshev gepar...@gmail.com wrote: This stopped working in 1.3.0. The caught exception does not match EntityNotFoundException; it is now a RuntimeException with the original typed exception chained to it. This caused me some pain in clojure.java.jdbc and I actually catch RuntimeException inside the library and unwrap it and throw the underlying SQLException (for transactions): ;; This ugliness makes it easier to catch SQLException objects ;; rather than something wrapped in a RuntimeException which ;; can really obscure your code when working with JDBC from ;; Clojure... :( (letfn [(throw-non-rte [ex] (cond (instance? java.sql.SQLException ex) (throw ex) (and (instance? RuntimeException ex) (.getCause ex)) (throw-non-rte (.getCause ex)) :else (throw ex)))] (throw-non-rte e))) I've had to do similar things in my own code to get at the underlying exceptions... It would be much, much friendlier to have (try .. (catch ..)) automatically unroll RuntimeException on demand so the obvious code works. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: docs for 1.3
My last mail remain unnoticed, so I'll clarify the question: Clearly (the main) clojure.org is not the main documentation source for 1.3. To prove it - try to find the mention of Factory function taking a map, e.g. map-MyRecord there. So what is the best search strategy right now to find the correct up-to-date documentation for 1.3? I suppose it's https://github.com/clojure/clojure/blob/master/changes.txt with all the linked documents and only then clojure.org . Is it right? Do I miss anything? -- 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
Re: docs for 1.3
On Mon, Oct 3, 2011 at 2:05 PM, Sergey Didenko sergey.dide...@gmail.com wrote: Clearly (the main) clojure.org is not the main documentation source for 1.3. To prove it - try to find the mention of Factory function taking a map, e.g. map-MyRecord there. The defrecord improvements seem to be covered here. http://dev.clojure.org/display/design/defrecord+improvements (it doesn't help that this is now a child page of Release.Next Planning which now refers to Clojure 1.4!) The API documentation is auto-generated from the source code so it's up-to-date (as I understand it): http://clojure.github.com/clojure/clojure.core-api.html But the API documentation isn't comprehensive (hard to be since it's essentially the docstrings in the code). Improving documentation looks to be a focus of Clojure 1.4: http://dev.clojure.org/display/design/Release.Next+Planning -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Re: ANN: tools.trace 0.7.1
Oups, this one slipped.. I'll fix in the README now... On Mon, 03 Oct 2011 22:46:42 +0200 Rob Wolfe r...@smsnet.pl wrote: Luc Prefontaine lprefonta...@softaddicts.ca writes: [...] Just add: [org.clojure/tools.trace 0.7.1] to your dependency list in your project.clj. This should be a straight replacement for clojure.contrib.trace in your code. If you find suggestions/improvements it's time to let me know about them. Src code and README at: https://github.com/clojure/tools.trace It seems that instead of #Usage: (ns your-namespace (:require tools.trace)) it should be: #Usage: (ns your-namespace (:require clojure.tools.trace)) Br, Rob -- Luc P. The rabid Muppet -- 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
Re: ANN: tools.trace 0.7.1
Done... no need to re-publish yet. Thanx Luc On Mon, 3 Oct 2011 19:04:58 -0400 Luc Prefontaine lprefonta...@softaddicts.ca wrote: Oups, this one slipped.. I'll fix in the README now... On Mon, 03 Oct 2011 22:46:42 +0200 Rob Wolfe r...@smsnet.pl wrote: Luc Prefontaine lprefonta...@softaddicts.ca writes: [...] Just add: [org.clojure/tools.trace 0.7.1] to your dependency list in your project.clj. This should be a straight replacement for clojure.contrib.trace in your code. If you find suggestions/improvements it's time to let me know about them. Src code and README at: https://github.com/clojure/tools.trace It seems that instead of #Usage: (ns your-namespace (:require tools.trace)) it should be: #Usage: (ns your-namespace (:require clojure.tools.trace)) Br, Rob -- Luc P. The rabid Muppet -- 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
Re: Exception handling changes in Clojure 1.3.0
On Oct 3, 12:27 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: Catching checked exceptions seems to work fine. Try e.g. (try (throw (java.io.IOException.)) (catch java.io.IOException _ caught!)) I suspect something else is going wrong in the GAE example. Can you narrow the code down to a block you can quote in full here? Your example works because it doesn't trigger the use of clojure.lang.Reflector. I'm having a hard time isolating a good example where an exception passes through Reflector on its way from Java into Clojure. (It doesn't happen when trivially calling simple methods on simple Java classes.) Here is the relevant stack trace, however. The top level invocation of DatastoreServiceImpl.get throws the exception (level 0), and I hope to catch it in retrieve (level 9). 0: com.google.appengine.api.datastore.DatastoreServiceImpl.get(DatastoreServiceImpl.java: 64) 1: sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 2: sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) 3: sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) 4: java.lang.reflect.Method.invoke(Method.java:597) 5: clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:92) 6: clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:30) 7: appengine_magic.services.datastore $retrieve_helper.doInvoke(datastore.clj:363) 8: clojure.lang.RestFn.invoke(RestFn.java:521) 9: appengine_magic.services.datastore $retrieve.doInvoke(datastore.clj:376) -- 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
Waiting for swank-clojure to be ready.
Hi, I'm currently redoing my Clojure setup and I wonder how to make Emacs wait for swank-clojure to be ready before calling slime-connect. I've added a shortcut to start swank-clojure: (global-set-key [f8] '(lambda () (interactive) (start-process swank-clojure swank-clojure ~/.lein/bin/swank-clojure) ;; should wait for swank-clojure to be ready (slime-connect 127.0.0.1 4005))) but I don't have any idea how to do the waiting part. -- 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
Re: Waiting for swank-clojure to be ready.
On Mon, Oct 3, 2011 at 5:12 PM, Nicolas Buduroi nbudu...@gmail.com wrote: Hi, I'm currently redoing my Clojure setup and I wonder how to make Emacs wait for swank-clojure to be ready before calling slime-connect. You can use M-x clojure-jack-in, but that only works for Leiningen projects out of the box. The other place I'd look is M-x durendal-jack-in, which was its mostly-deprecated precursor. It has a less comprehensive bootstrap mechanism, but if you've already got slime-repl installed then that shouldn't be an issue. https://github.com/technomancy/durendal/blob/master/durendal.el#L82 -Phil -- 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
Re: Waiting for swank-clojure to be ready.
Thanks, this was really helpful. Here's what my shortcut looks like now: (global-set-key [f8] '(lambda () (interactive) (start-process swank-clojure *swank-clojure* ~/.lein/bin/swank-clojure) (set-process-filter (get-buffer-process *swank-clojure*) (lambda (process output) (when (string-match Connection opened on output) (slime-connect localhost 4005) (with-current-buffer (slime-output-buffer t) (setq default-directory root)) (set-process-filter process nil)) On Mon, Oct 3, 2011 at 8:33 PM, Phil Hagelberg p...@hagelb.org wrote: On Mon, Oct 3, 2011 at 5:12 PM, Nicolas Buduroi nbudu...@gmail.com wrote: Hi, I'm currently redoing my Clojure setup and I wonder how to make Emacs wait for swank-clojure to be ready before calling slime-connect. You can use M-x clojure-jack-in, but that only works for Leiningen projects out of the box. The other place I'd look is M-x durendal-jack-in, which was its mostly-deprecated precursor. It has a less comprehensive bootstrap mechanism, but if you've already got slime-repl installed then that shouldn't be an issue. https://github.com/technomancy/durendal/blob/master/durendal.el#L82 -Phil -- 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 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
Re: Problem Running ClojureScript on OpenJDK
Works for me. Thanks.
On Oct 3, 10:15 am, Brenton bashw...@gmail.com wrote:
If you have been having problems the ClojureScript and OpenJDK, please
try the current master branch of ClojureScript.
I would be interested to know what problems still remain, if any,
after these changes.
On Oct 2, 11:07 pm, db donald.bl...@gmail.com wrote:
Here's what the patch looks like for openjdk-6 with the latest master,
where the mozilla-specific lines have moved to the rhino.js file:
diff --git a/src/clj/cljs/repl/rhino.clj b/src/clj/cljs/repl/rhino.clj
index cbe4f2a..15c5bf1 100644
--- a/src/clj/cljs/repl/rhino.clj
+++ b/src/clj/cljs/repl/rhino.clj
@@ -27,6 +27,7 @@ goog.require = function(rule)
{Packages.clojure.lang.RT[\var\
linenum (or line Integer/MIN_VALUE)
ctx (sun.org.mozilla.javascript.Context/enter)]
(try
+ (.setOptimizationLevel ctx -1)
{:status :success
:value (.evaluateString ctx (:global repl-env) js filename
linenum nil
(finally
This works for me on openjdk6, but will not work on openjdk7 because
it doesn't ship with Rhino. For openjdk7, it looks like a separate
version of Rhino needs to be downloaded.
On Oct 2, 4:36 pm, Stefan Kamphausen ska2...@googlemail.com wrote:
Hi,
I hope, people are aware that Oracle considers OpenJDK to be the standard
choice for Linux users now and removed the special distributor's license.
Seehttp://robilad.livejournal.com/90792.html
Kind regards,
Stefan
--
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
