Re: better error messages > smaller stack traces
On Tue, Feb 08, 2011 at 09:01:38AM -0500, Stuart Halloway wrote:
> Please let us know when you get a misleading error message from a
> macroexpansion, so we can make it better. Or contribute a patch along the
> lines
> of [2].
Here's a misleading lack of an error message:
(defn foo [x]
{:pre (odd? x)}
x)
The code may look fine at a glance, but the precondition is not
wrapped in a seq, so the actual preconditions become checks for
truthiness of `odd?` and `x`.
Maybe precondition forms should be required to be vectors, so that
function call forms can't be mistaken for lists of preconditions?
--
Timo
--
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: better error messages > smaller stack traces
On Mon, Feb 14, 2011 at 5:48 AM, Timo Mihaljov wrote:
> On Tue, Feb 08, 2011 at 09:01:38AM -0500, Stuart Halloway wrote:
>> Please let us know when you get a misleading error message from a
>> macroexpansion, so we can make it better. Or contribute a patch along the
>> lines
>> of [2].
>
> Here's a misleading lack of an error message:
>
> (defn foo [x]
> {:pre (odd? x)}
> x)
>
> The code may look fine at a glance, but the precondition is not
> wrapped in a seq, so the actual preconditions become checks for
> truthiness of `odd?` and `x`.
>
> Maybe precondition forms should be required to be vectors, so that
> function call forms can't be mistaken for lists of preconditions?
+1
--
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
Realtime Clojure program
For a while I've been working on a 2D physics engine written in Clojure. I just recently got to the point where I can run a simulation(a box falling onto the ground) and it is painfully slow. I'm shooting for 60 fps but I can barely get 10 when the box is falling and when it lands on the ground and the collision response kicks in I get about 5. The project has reached a size where I thought it would be silly to ask for specific ways to speed up but I thought I could at least ask a general question. I have heard that Clojure is not suited for programs that need to run in real time, is that 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
Re: Type hinting question
On Java HotSpot: -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly You'll need quite a few iterations, and be wary of code with no observable effect (becomes subject to dead code elimination). As far as I could tell cast or no cast made no difference at all (in this particular case). /Johan Wirde On Sun, Feb 13, 2011 at 4:05 PM, Stuart Sierra wrote: > Modern JVMs like HotSpot are very good at eliminating unnecessary > instructions. Unfortunately, I haven't heard of a good tool for observing > this process, so you either have to take it on faith or go read the OpenJDK > source code. > > -Stuart Sierra > 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 > -- 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: Realtime Clojure program
On Sun, Feb 13, 2011 at 5:50 PM, Jarl Haggerty wrote: > For a while I've been working on a 2D physics engine written in > Clojure. I just recently got to the point where I can run a > simulation(a box falling onto the ground) and it is painfully slow. > I'm shooting for 60 fps but I can barely get 10 when the box is > falling and when it lands on the ground and the collision response > kicks in I get about 5. > > The project has reached a size where I thought it would be silly to > ask for specific ways to speed up but I thought I could at least ask a > general question. > > I have heard that Clojure is not suited for programs that need to run > in real time, is that true? No. But you need to optimize carefully to make the inner loop fast. 1. Give some thought to the algorithm. Are you recalculating something you could reuse? Are you calculating something you never use? 3D games get a big speed boost from ignoring or reducing the precision of calculations for things that take place out of sight or far from any player's vantage point. There may be similar speedups possible in your physics engine. For example, objects in static equilibrium can be flagged "ignore" until something touches them. 2. Do not use global vars in your inner loop. Copy them to a local first: (def my-constant 42) ... (let [my-constant my-constant] (loop [...] ...)) Clojure's Var objects involve Java ThreadLocals. ThreadLocals are slow. 3. That applies to functions too, including clojure.core functions. But see below. 4. Unless you're using 1.3 or later, put the innermost loop in a single function and try to avoid calling sub-functions, except for operators like + that can get inlined. 5. Working inside a single function lets you use unboxed primitive arithmetic: (let [t (int 3) u (int some-variable)] ...) and likewise with loop. 6. Binary +, *, -. and / are particularly fast on primitives; unchecked-add etc. are even faster but wrap around on overflow. 7. The recurs in a loop with primitives need to have corresponding primitive types where the loop variables are primitive. If you get errors about recur args needing to be primitive, your math is still getting boxed somewhere. 8. If there are any Java method calls in your inner loop, type hint the heck out of the references to the objects you call them on to avoid reflection, which is uberslow. Use (set! *warn-on-reflection* true) to locate places where reflection is still being used. 9. Sometimes the fastest algorithm is a dirty one. If need be, use arrays. They're mutable, can hold primitives, but sure as hell aren't thread safe. Don't let arrays escape the thread that uses them, or preferably even your inner-loop function. If an array holds the result and the array isn't huge copy it into a vector with (into [] the-array) and return the vector, after exiting the loop. Otherwise call seq on it and return that, though that's a bit less thread-safe: if two of the elements are realized and a third gets twiddled, the third element of the seq will come out the altered value instead of the one that was in the array when the seq was constructed. 10. Watch for reflection warnings when using arrays. Don't bother with aset-int and friends either. 11. If you really must you can always drop down to Java for the bits that need to be fastest. But this is rarely if ever actually necessary. Post specific bits that are giving you trouble (recalcitrant reflection warnings, etc.) here if you continue to have trouble. -- 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: Realtime Clojure program
On Feb 13, 7:50 pm, Jarl Haggerty wrote: > I'm shooting for 60 fps but I can barely get 10 when the box is > falling and when it lands on the ground and the collision response > kicks in I get about 5. > > The project has reached a size where I thought it would be silly to > ask for specific ways to speed up but I thought I could at least ask a > general question. Have you tried: (set! *warn-on-reflection* true) Adam Burry -- 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: Help - .class files and GAE's "too many files" problem
Hmm, thanks for pointing it out! In fact I was about to make the move from appengine-clj to appengine-magic, but just because you make multipart (image) uploading a little bit easier, as well as providing a better query syntax (e.g., you support the offset parameter, which I now have to mimic by hand). I must have skipped the part where you handle my current problem - perhaps because i didn't know about its existence before :) Couple of questions: 1. you seem to be using the 1.3.7 GAE SDK - right now I'm using 1.4.0, and I've been being warned that 1.4.2 is out. Do you think it would be hard to update appengine-magic to work with the newer SDK? 2. right now I'm deploying a couple of servlets that don't include nothing but the bare minimum for a Servlet. Think of a Ping server, for instance. I'm making these separate from the core servlet assuming it'll start faster in case the java instance on GAE is not warmed up. How do you advise me to configure my project so that more than that core servlet gets uploaded as a .class? -- 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.contrib.condition
2011/2/8 Brian Marick : > The header documentation for clojure.contrib.condition says: > > Note: requires AOT compilation. > > What do I therefore do differently? How should my program text change? The clojure-contrib jar file that your build tool - or yourself, if you do stuff manually - downloaded contains an ahead of time compiled version of that namespace. So, unless you compile contrib yourself, you shouldn't have to do anything special. > Conditions seem to work in the REPL, but not in my program. I don't know if > that's due to the mysteries of AOT compiling or something else I'm doing > wrong. Please enlighten. I guess that depeds on what you mean by "in my program". (The way I do development, I would consider my program and the repl to be the same thing.) I think this is a problem caused by how you launch clojure. Do you use leiningen, cake or something else (if manually, how have you set up the class path)? What behaves differently if you run (require 'clojure.contrib.condition) in the repl and "in your program"? // raek -- 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: Realtime Clojure program
Laziness is great when there are things that may not ever be needed. But it slows things down when you know that you are going to need some function applied to every element of some col. The doall function is your friend in this case. If there are things that you are using pmap on then I would open up a systems console that let's you see the load being placed on each processor, and see if there are areas of the code that aren't using all of the cores fully. (This works a lot better on my core i7 processor at home, than it does on the dual core processor at work.) I would than start applying doall to each of the map and pmap commands and figure out what is causing the slow down. With a judicious use of doall I have seen a 10-20 fold speed increase in some of my code. On Feb 13, 5:50 pm, Jarl Haggerty wrote: > For a while I've been working on a 2D physics engine written in > Clojure. I just recently got to the point where I can run a > simulation(a box falling onto the ground) and it is painfully slow. > I'm shooting for 60 fps but I can barely get 10 when the box is > falling and when it lands on the ground and the collision response > kicks in I get about 5. > > The project has reached a size where I thought it would be silly to > ask for specific ways to speed up but I thought I could at least ask a > general question. > > I have heard that Clojure is not suited for programs that need to run > in real time, is that 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
Can gen-class create classes with native methods?
i.e. is there a way in a Clojure source file to generate a class like
the one named GmpUtil in this Java program?
http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=java&id=4
(class GmpUtil is near the end of the program -- here is a copy)
class GmpUtil {
static {
System.loadLibrary("jpargmp");
}
static native long mpz_init();
static native void mpz_clear(long src);
static native void mpz_mul_si(long dest, long src,
int val);
static native void mpz_add(long dest, long src,
long src2);
static native void mpz_set_si(long src, int value);
static native int mpz_get_si(long src);
static native int mpz_cmp(long dest, long src);
static native void mpz_tdiv_qr(long q, long r, long n,
long d);
}
I know that I can put that code into its own separate Java source
file, compile it to a class file, and use that class from a Clojure
program, although I've only found a way to do it if I put it into a
named package, e.g. I add a line "package gmp;" at the beginning of
the Java source file, and then import that package in the Clojure
source file.
A second question would be: Is there a way to compile such a Java
source file into the default package, and then use the class GmpUtil
from a Clojure program whose code is also compiled into the default
package? I know that there are limitations with the default package
in Java and Clojure, but not all the details of what those
restrictions are.
Thanks,
Andy
--
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: Newbie: What's your opinion about this Clojure code?
With a little practice and/or tools, you'll find you rarely have to find the right position. Rainbow-parens is one option, which makes matching parens the same color; one that I use more often is C-M-f, which moves from the start of a sexp to its end. So if you want to put something at the end of a (let [a b] ...) form, you can put point on the (, C-M-f, C-b (to move before the close paren), and start writing. I haven't read your code, and I'm sure Ken's suggestions are as good as they usually are, but I have a suggestion you might find interesting. (let [reader (reader blah) writer (writer blah)] ...) Could be rewritten as (let [[reader writer] ((juxt reader writer) blah)] ...) if you were so inclined. Whether it's better is a matter of taste, but it's a nice sample of the kinds of neat things you can do with Clojure. On Feb 13, 11:10 pm, Nick Wiedenbrueck wrote: > Thanks a lot. > > I'll have to get used to closing all parentheses of a function on a > single line, cause this makes finding the right position when editing > the code afterwards a little harder. Also now I got the clojure mode > for emacs (instead of lisp mode) to get the indentation right. -- 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: Newbie: What's your opinion about this Clojure code?
Er, not sure why I thought Ken was the one answering you. Maybe it just read like him. I was referring to James, of course, since he was the only person who had answered. On Feb 14, 10:40 am, Alan wrote: > With a little practice and/or tools, you'll find you rarely have to > find the right position. Rainbow-parens is one option, which makes > matching parens the same color; one that I use more often is C-M-f, > which moves from the start of a sexp to its end. So if you want to put > something at the end of a (let [a b] ...) form, you can put point on > the (, C-M-f, C-b (to move before the close paren), and start writing. > > I haven't read your code, and I'm sure Ken's suggestions are as good > as they usually are, but I have a suggestion you might find > interesting. > > (let [reader (reader blah) > writer (writer blah)] > ...) > > Could be rewritten as > > (let [[reader writer] ((juxt reader writer) blah)] > ...) > > if you were so inclined. Whether it's better is a matter of taste, but > it's a nice sample of the kinds of neat things you can do with > Clojure. > > On Feb 13, 11:10 pm, Nick Wiedenbrueck > > wrote: > > Thanks a lot. > > > I'll have to get used to closing all parentheses of a function on a > > single line, cause this makes finding the right position when editing > > the code afterwards a little harder. Also now I got the clojure mode > > for emacs (instead of lisp mode) to get the indentation right. > > -- 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
free JVMs vs Enterprise JVMs
I am sorry if this question has been asked and answered, but I didn't see it when I searched. Has anyone really looked at the performance benefits, when running clojure, of the different JVM's that are out there? For example, I use the stock JVM that comes with my operating system. But, would I see much of a performance increase if I went to an enterprise JVM? -- 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 gen-class create classes with native methods?
`gen-class` only creates stub classes. The methods in the generated classes
just invoke the Clojure functions by name, as if you wrote
`RT.var("namespace", "function").invoke()` in Java. That is to say,
gen-class can't generate native methods.
I don't think Clojure can import Java classes without a package name, but
I'm not sure.
-Stuart Sierra
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: Type hinting question
Thanks, Johan! -S -- 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: free JVMs vs Enterprise JVMs
It really depends on your application. I am not aware of any benchmarks of Clojure programs on different JVMs. A typical Clojure program puts more stress on the garbage collector than a typical Java program, so JVMs with optimized garbage collection may perform better. Whatever JVM you use, make sure you are familiar with its performance-tuning settings, such as heap size and garbage collection strategy. -Stuart Sierra 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: Realtime Clojure program
On Feb 14, 4:32 pm, cej38 wrote: > Laziness is great when there are things that may not ever be needed. > But it slows things down when you know that you are going to need some > function applied to every element of some col. The doall function is > your friend in this case. AFAIK, most if not all of the lazy constructs in clojure have a penalty attached that is only applied the first time you realize the sequence. Executing a doall on a lazy seq does not reduce the penalty (and probably makes the overall running time slightly longer). But there might be exceptions to that, that I don't know about. For speedy and clever algorithms, not using lazy constructs at all and modifying stuff in-place is probably the way to go, though I would certainly advice against doing that before there is a working "clean" solution that's been tested to show where the actual slow stuff resides. Profiling is generally much better than intuition. J. -- 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: better error messages > smaller stack traces
Hello. There is an interesting model about error reporting: Clang, one of C-family languages compiler which uses LLVM. For example, if you mistake names, Clang searches similar names which really exist in current environment. And then Clang illustrates line, column and actual code. If you want to get more informations, see [1]. Of course, they needs more works and error reporting may slow down. Also, Clojure has non-preprocessor macro and JVM exception handling, so we can't reproduce Clang truly. However, we can learn some from Clang, I think. Thank you. [1] http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html -- Name: OGINO Masanori (荻野 雅紀) E-mail: masanori.og...@gmail.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
[ANN] emacs-nexus (Emacs client for Nexus Maven repository servers)
Hi, Although Emacs is a great environment for writing Clojure code and Leiningen/Cake makes Maven builds less painful, you still had to switch from your Emacs environment to your web browser to search for Maven artifacts. emacs-nexus is a minimal (elisp-only) Nexus client to search for artifacts and display Leiningen/Maven dependencies: https://github.com/juergenhoetzel/emacs-nexus Any feedback/contribution is appreciated. Jürgen -- 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] emacs-nexus (Emacs client for Nexus Maven repository servers)
On Mon, Feb 14, 2011 at 7:21 PM, Jürgen Hötzel wrote: > Hi, > > Although Emacs is a great environment for writing Clojure code and > Leiningen/Cake makes Maven builds less painful, you still had to > switch from your Emacs environment to your web browser to search for > Maven artifacts. > > emacs-nexus is a minimal (elisp-only) Nexus client to search for > artifacts and display Leiningen/Maven dependencies: > > https://github.com/juergenhoetzel/emacs-nexus > > Any feedback/contribution is appreciated. > > Cool, maybe search clojars by default also? Scott -- 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] emacs-nexus (Emacs client for Nexus Maven repository servers)
On Mon, Feb 14, 2011 at 16:50, Scott Jaderholm wrote: > On Mon, Feb 14, 2011 at 7:21 PM, Jürgen Hötzel wrote: > >> Hi, >> >> Although Emacs is a great environment for writing Clojure code and >> Leiningen/Cake makes Maven builds less painful, you still had to >> switch from your Emacs environment to your web browser to search for >> Maven artifacts. >> >> emacs-nexus is a minimal (elisp-only) Nexus client to search for >> artifacts and display Leiningen/Maven dependencies: >> >> https://github.com/juergenhoetzel/emacs-nexus >> >> Any feedback/contribution is appreciated. >> >> > Cool, maybe search clojars by default also? > Along with anything that is listed in :repositories in your project.clj ? > > Scott > > -- > 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
Project Euler problem 28
Hi all, Does anyone wanna have a look at my solution for Project Euler Problem 28? (defn diagonal-sum [n-max] (+ 1 (reduce + (map (fn[n] (reduce + (map #(- (* n n) (* % (- n 1))) (range 4 (take-nth 2 (range 3 (+ 2 n-max))) The function does the job. The solution takes about 1.5msec on my machine to compute. I'd like to discuss more performant and/or more idiomatic solutions to that problem :) The parts I'm not quite happy with are the take-nth and range constructs with all the magic numbers in there... Cheers Andreas -- "Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP -- ** Andreas Koestler, Software Engineer Leica Geosystems Pty Ltd 270 Gladstone Road, Dutton Park QLD 4102 Main: +61 7 3891 9772 Direct: +61 7 3117 8808 Fax: +61 7 3891 9336 Email: andreas.koest...@leica-geosystems.com www.leica-geosystems.com* when it has to be right, Leica Geosystems Please consider the environment before printing this email. -- 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
Summer of Code 2011
I know in the past there's been interest in the Clojure community in participating in Google's Summer of Code program. LispNYC has been a mentoring organization for SoC a number of times, and though we missed the last couple of years, we're gearing up to participate again in 2011. Right now we're looking for project ideas and I want to make sure that the Clojure community is involved. For those not familiar with this program, each year since 2005 Google has sponsored students from all over the world to work on open source software during their summer break. Rather than work directly with Google however, students work with a mentoring organization, like LispNYC. Students give their project proposals to us, we rank them, and Google grants us funding for the top n projects, where n is a number decided by Google. The program's primary goal is to get students involved with open source, and I can think of few projects more apt for this purpose than Clojure. I'm making a personal appeal to the Clojure community for project ideas because I think it's an ideal place for a young developer to get introduced to the open source and lisp communities. The Clojure community is one of the friendliest and welcoming of these kinds of groups. Furthermore, the state of Clojure as a rapidly maturing but still quite young platform means more opportunity for students to make a substantial contribution they can be proud of. We're interested in project ideas of all types: fun projects and practical projects; projects for Clojure newbies and projects for Clojure mavens. Is there a library you wish existed for Clojure? Support missing for your favorite IDE? A feature that's been missing from your favorite Clojure project? Or maybe if you hack on clojure.core you have ideas for projects that involve changes to the language itself. Whatever your idea is, we want to hear it. You may be wondering why I'm talking about a summer program in February; the answer is that the organization application period is the first week in March. If you'd like to contribute a project idea, please use the form at http://lispnyc.org/soc/idea. If you have any questions, please participate in the discussion on our mailing list ( http://www.lispnyc.org:8080/mailman/listinfo/summeroflisp-discuss/) or in #summeroflisp on freenode. We're also starting to look for mentors, so if you're interested in that, please let me know. Thanks, and here's looking forward to a great summer. /brian -- 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] emacs-nexus (Emacs client for Nexus Maven repository servers)
2011/2/15 Michael Ossareh : > > > On Mon, Feb 14, 2011 at 16:50, Scott Jaderholm wrote: >> >> On Mon, Feb 14, 2011 at 7:21 PM, Jürgen Hötzel >> wrote: >>> >>> Hi, >>> >>> Although Emacs is a great environment for writing Clojure code and >>> Leiningen/Cake makes Maven builds less painful, you still had to >>> switch from your Emacs environment to your web browser to search for >>> Maven artifacts. >>> >>> emacs-nexus is a minimal (elisp-only) Nexus client to search for >>> artifacts and display Leiningen/Maven dependencies: >>> >>> https://github.com/juergenhoetzel/emacs-nexus >>> >>> Any feedback/contribution is appreciated. >>> >> >> Cool, maybe search clojars by default also? > > Along with anything that is listed in :repositories in your project.clj ? The actual searching/indexing is done by the Nexus server. Emacs-nexus is just a client for the REST API provided by Nexus. To search Clojars we need a public Nexus server indexing the Clojars Maven repo. Jürgen -- 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
