Re: Compiling gen-class runs static initializers: workarounds, solutions?
The JavaFX workaround consist of creating a javafx.embed.swing.JFXPanel statically in a namespace that is loaded before any other namespace that import problematic JavaFX classes as in [1,2]. This initializes the JavaFX platform. [1] https://github.com/halgari/fn-fx/blob/master/src/fn_fx/render_core.clj#L20 [2] https://github.com/zilti/clojurefx/blob/master/src/clojurefx/core.clj#L7 -- 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/d/optout.
Re: ANN: Specter 0.11.0, performance without the tradeoffs
Following the convention not to use `def` in non-top-level positions, you should use `intern` instead of `def`. -- 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/d/optout.
Re: Optimizing code : Fun but now paining me
I spot the following problems in your code with respect to primitive functions: 1. You declare functions (ModAdd, ...) with primitive arguments but without primitive return values. So you get boxing on the return values. 2. You pass those primtive functions as argument to EulerPowNonMemoized, you won't get a primitive invocation (.invokePrim opr ...) in that function since the Clojure compiler does only generate primitive invocations for direct calls to primitive functions. Hence, you end up with (.invoke opr ...) and boxing instead. 3. The built-in memoize will also box your arguments and memoized return values again. -- 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/d/optout.
Re: Advice on managing random number generators across threads
In Java 7 you would use ThreadLocalRandom you said in another thread. Well, in Java 6 you already have ThreadLocal [1] and thus you are able to build a thread local Random yourself to keep Java 6 as minimum requirement. [1] http://docs.oracle.com/javase/6/docs/api/index.html?java/lang/ThreadLocal.html -- 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/d/optout.
Re: Allow reseeding/rebinding RNG behind rand?
Once you notice that you usually need a fast solution. The easiest solution is to just pass around an instance of java.util.Random which you create with the desired seed. Another options is to have a constructor function returning a rand function. (defn prng [seed] (let [rnd (java.util.Random. (long seed))] (fn rand [] (.nextDouble rnd You can specify different arities as you need them. But obviously this is more limited than just passing around the Random object since you can't choose between the next* methods. But having a built-in rebindable (thread-local) rand is preferable in the long run. -- 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/d/optout.
Re: Licensing program written in Clojure under GPL
Program B will be released as source. So in this case I can choose the license of program B independently since it is no derivative work of library G? As far as I read a hint that program B is not derivative work of library G is that I could exchange library G with a different library which implements similar functionality. In general it would be helpful to gather information about these licensing issues for Clojure library authors. @Colin: Library G is in fact a Java library. -- 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/d/optout.
Licensing program written in Clojure under GPL
I have written a Clojure library A which is licensed under Eclipse Public License (EPL) as usual which depends on other Clojure libraries with EPL license. In a different program B I use library A and another library G which is licensed under GPLv3. Now, the question arises which license I am allowed to use (or even must use) for program B. As far as I have read it is not possible to license B under EPL because library G is licensed under GPLv3. Leaving the only option to license program B under GPLv3 - does that sound correct to you? -- 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/d/optout.
Re: Different behaviour when using (def ^:macro ...) outside top-level
`def` does not handle `:macro true` metadata on the provided symbol. But you can work around that like clojure.core does, e.g. for the macro `defmacro` after the `(def ... defmacro ...)` call the following is called: `(. (var defmacro) (setMacro))` -- -- 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: Best way to pass through named arguments (destructured map)?
You can also checkout whether my library [1] suits you. Passing option maps to other functions with options and managing doc strings for these options (transitively) are the features it was written for. It will simplify functions with options in your own code but the calls to functions of third party libraries will remain the same. [1] https://github.com/guv/clojure.options/ -- -- 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: I tripped out
You might be interested in https://github.com/guv/clojure.options/ -- -- 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: Parallel let form
It is not broken. It fulfills the discussed goal of having independent parallel calls in a let-like macro. Thus the name plet. Using a previous binding in another binding of plet was no goal. Therefore you can use the normal let macro. In a library one should add the intention to use it only for independent parallel calls to the doc string. Am Samstag, 27. April 2013 17:59:13 UTC+2 schrieb Ben: guv is broken if your let form introduces bindings that depend on earlier bindings: user= (plet [a 2 b a] b) CompilerException java.lang.RuntimeException: Unable to resolve symbol: a in this context, compiling:(NO_SOURCE_PATH:1) user= (clojure.pprint/pprint (macroexpand-1 '(plet [a 2 b a] b))) (clojure.core/let [G__364 (clojure.core/future 2) G__365 (clojure.core/future a) ;;; oops! a @G__364 b @G__365] b) nil user= In fact, both of them are broken in this way. On Sat, Apr 27, 2013 at 6:55 AM, Glen Mailer glen...@gmail.comjavascript: wrote: Hi All, I was recently looking at how to make better use of parallelisation for simple tasks in my compojure app, I had a construction similar to the following: (views/some-view (api/api-call-1) (api/api-call-2) (api/api-call-3)) It seemed that the easiest way to introduce some parallelism here would be in the style of a let form: (let [result-1 (api/api-call-1) result-2 (api/api-call-2) result-3 (api/api-call-3)] (views/some-view result-1 result-2 result-3) There doesn't appear to be anything in core that does, this - after a brief discussion in the IRC channel, I received the following two suggestions: https://gist.github.com/jcromartie/5459350 and https://gist.github.com/guv/5459364 I ended up going with the approach from guv, as I understood it better - and I moved the let form inside the view function to cut down on the repetition a bit. Now, to my actual questions: What are the differences between the pmap approach and the futures approach? And would a construction like this be useful in core? If so, how does it potentially get there? Thanks Glen Mailer Budding Clojurer -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- 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: Performance of calling primitive type hinted functions passed as arguments
Some time ago I dug into primitive type hints and how the Clojure compiler uses them. When the compiler finds primitive type hints on a function, say (defn f [^long n] ...), the generated class for that function implements a primitive interface, IFn$LO in this case, and generates appropriate code in the interface's only method Object invokePrim(long arg0). For a defn which is used as symbol in code the compiler detects the primitive interface and generates code using invokePrim if the infered type of the parameters matches. Long story short, currently the compiler is not able to use primitive invocation for higher order functions automatically because it would need to generate code that checks at runtime. You can fix this with Java interop. I implemented an `invoke-primitive` macro over here: https://gist.github.com/guv/5458038 It could be used like follows: (defn calc [^long n] ...) (defn dosomething [f, ^long n] (invoke-primitive O [L] f n)) The macro expands to (.invokePrim ^IFn$LO f n) using several checks at compile time. Am Mittwoch, 24. April 2013 19:15:49 UTC+2 schrieb Alice: So, is there a way to type hint on cb that it has a function accepting a long argument? On Apr 25, 12:55 am, Stuart Sierra the.stuart.sie...@gmail.com wrote: I'm taking a guess here: The compiler doesn't know the type signature of `cb` when compiling `foo`, so it's going to use the IFn.invoke(Object) signature. Clojure's type inference is only local, and it won't assume that a primitive-type signature is available for an arbitrary function. So there's probably some extra typecasting going on when `fn` is type-hinted to a primitive. In general, type-hinting to primitive types doesn't do you any good in the presence of higher-order functions like `map`. -S On Wednesday, April 24, 2013 11:35:11 AM UTC-4, Alice wrote: (defn foo [^long l cb] (cb l)) (time (dotimes [n 100] (foo n (fn [l] nil (time (dotimes [n 100] (foo n (fn [^long l] nil Elapsed time: 7.861 msecs Elapsed time: 11.770973 msecs Why is the latter slower? -- -- 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: Problems building CounterClockwise
I wanted to point you to the developer instructions over here: http://code.google.com/p/counterclockwise/wiki/HowToBuild But apparently they changed 4 days ago. The previous description there worked for me. Try the new description there and if it fails, report an issue on that google code project. -- -- 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: alternative to passing parameters to functions
You can checkout clojure.options (https://github.com/guv/clojure.options/). One of its main features is documentation for options (even transitive ones in calls to other functions with options). -- -- 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: Primitive function boxes and unboxes result value
I think Cristophe is on the right path. But it is possible that there is another Bug concerning primitive functions. Consider the following two functions: (defn fib ^long [^long n] (if (= n 1) 1 (+ (fib (dec n)) (fib (- n 2) (defn fib2 ^double [^double n] (if (= n 1) 1 (+ (fib2 (dec n)) (fib2 (- n 2) The bytecode of `fib` ends as expected with 42 invokestatic 81; /* long clojure.lang.Numbers.minus(long arg0, long arg1) */ 45 invokeinterface 77 3; /* long invokePrim(long arg0) */ 50 invokestatic 84; /* long clojure.lang.Numbers.add(long arg0, long arg1) */ 53 lreturn; But `fib2` boxes and unboxes again: 45 invokestatic 83; /* double clojure.lang.Numbers.minus(double arg0, long arg1) */ 48 invokeinterface 79 3; /* double invokePrim(double arg0) */ 53 invokestatic 87; /* double clojure.lang.Numbers.add(double arg0, double arg1) */ 56 invokestatic 92; /* java.lang.Double java.lang.Double.valueOf(double arg0) */ 59 checkcast 94; /* java.lang.Number */ 62 invokevirtual 98; /* double doubleValue() */ 65 dreturn; I also rewrote the multiply-and-square algorithm so that it does not use `loop`: (defn multiply-and-square ^double [^double result, ^double factor, ^long c] (if ( c 0) (recur (if (first-bit? c) (* result factor) result), (* factor factor), (bit-shift-right c 1)) result)) (defn exp-int2 ^double [^double x, ^long c] (multiply-and-square 1.0, x, c)) Here the bytecode of `exp-int2` looks fine, but the recursive function `multiply-and-square` performs the boxing and unboxing again: 43 dload_1; /* result */ 44 invokestatic 70; /* java.lang.Double java.lang.Double.valueOf(double factor) */ 47 checkcast 72; /* java.lang.Number */ 50 invokevirtual 76; /* double doubleValue() */ 53 dreturn; Christophe, can you try `fib2` with your patched Clojure? -- 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: Primitive function boxes and unboxes result value
Of course. You are right. I did forget about the long constant. I hope your patch will be included in Clojure 1.5. -- 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
Primitive function boxes and unboxes result value
I have written a primitive function for exponentiation with integers as
power using the multiply-and-square algorithm.
For performance reasons I used primitive type hints for the arguments and
the return value.
Profiling the whole application I noticed that there are a lot of
java.lang.Double/valueOf calls.
Looking at the bytecode I see that in Clojure 1.3 as well as in Clojure 1.4
the result value gets boxed and unboxed like
Double.valueOf(result).doubleValue().
Am I doing something wrong? Is there a serious bug related to the support
of primitive functions?
The source code:
(defn first-bit?
{:inline (fn [n] `(== 1 (clojure.lang.Numbers/and ~n, 1)) )}
[^long n]
(== 1 (clojure.lang.Numbers/and n, 1)))
(defn exp-int
^double [^double x, ^long c]
(loop [result 1.0, factor x, c c]
(if ( c 0)
(recur
(if (first-bit? c)
(* result factor)
result),
(* factor factor),
(bit-shift-right c 1))
result)))
Last lines of the Java bytecode of `exp-int`:
59 dload 5; /* result */
61 invokestatic 40; /* java.lang.Double
java.lang.Double.valueOf(double c) */
64 checkcast 85; /* java.lang.Number */
67 invokevirtual 89; /* double doubleValue() */
70 dreturn;
--
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: Primitive function boxes and unboxes result value
I can add some additional information. I compiled the fibonacci example with double and long type hints: (defn fib ^long [^long n] (if (= n 1) 1 (+ (fib (dec n)) (fib (- n 2) (defn fib ^double [^double n] (if (= n 1) 1 (+ (fib (dec n)) (fib (- n 2) The one with ^long works as expected but the one with ^double has the Double.valueOf(result). doubleValue() bytecode before the return. -- 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: Possible to merge destructuring :or defaults with :as?
In case you are primarily interested in clojure functions with keyword arguments (or optional arguments), you might check if clojure.options (https://github.com/guv/clojure.options/) suits you. -- 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: Best practices for named arguments
Hello David. I have a very similar scenario according to named parameters liker you. Therefore I have written the library clojure.options which can be found here: https://github.com/guv/clojure.options The latest version is also on clojars. Greetings, Gunnar -- 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: Using JPPF in Clojure - Class Loading Issues
My first try to get JPPF to work from REPL is changing the ContextClassLoader to an implementation derived from clojure.lang.DynamicClassLoader which caches the class bytes on definition. That did not work so far. Sometimes (.setContextClassLoader (Thread/currentThread) cacheClassLoader) does not even seem to work - since (.getContextClassLoader (Thread/currentThread)) still returns a DynamicClassLoader afterwards. In case caching dynamically created classes will not be included in any future Clojure version, I want to be able to intercept class definition for the caching. The best scenario would be, if Clojure had a compiler option that creates class files for dynamically created classes like *compile-files* in Clojure's compiler does when using (compile 'my-ns). *compile-files* seems not usable for that case in REPL by simply binding it to true. -- 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
Using JPPF in Clojure - Class Loading Issues
JPPF is a Java framework to perform distributed execution of computation jobs. In my experiment to use JPPF (http://www.jppf.org) in Clojure I noticed a class loading problem. A JPPFTask implemenation created via 'proxy could not be loaded by the JPPF framework. As a result I got the following ClassNotFoundException: Could not load class 'clj_jppf_example.core.proxy$org.jppf.server.protocol.JPPFTask$0'. When AOT-compiling the corresponding namespace there is no problem. But AOT-compilation seems to be a strong restriction for distributed computation in pure Clojure projects. I have an example project for demonstration purposes on github: https://github.com/guv/clj-jppf-example Laurent from JPPF told me that the problem is a missing cache for the byte[] representation of dynamically generated classes. He suggested a change to Clojure's DynamicClassLoader that is adding an in-memory cache. Most likely, an in-memory cache is not suitable in general and that change should be extended to an on-disk file cache in a temporary directory. I hope we can discuss and realize a solution to use JPPF in Clojure without the need for AOT compilation. Sincerely, Gunnar -- 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
