Re: Will the JVM will always likely, remain the primary Clojure implementation ?
Having read the posts all over again, can I say that *the JVM will remain the primary target/platform for Clojure, while Oracle remains good i.e. it doesn't get Barmy *? Isn't that unforeseeable? On Thursday, December 27, 2012 4:56:52 PM UTC+5:30, Sukh Singh wrote: Hi, I have noticed that this question is randomly appearing in many minds, and it is frequently being asked, though there is no apparent reason on why it is asked :/ or maybe people are unable to pen down the exact reasons, and sad to say, even myself. There are reasons for which I ask this question - - People (Majority) tend to stick with the primary implementations of certain multi-implementation software. And in the case of Clojure, the JVM implementation is the primary implementation now. - Having a primary implementation in case of BDFL lead software helps as a glue in the community. For example , CPython is the primary python implementation, even if there is an existance of IronPython or JPython. - The doubts of many, including me, will be cleared by an abstract answer... That 'many' also include the companies adopting something new, in this particular case, adopting clojure *QUESTION* Rich Hickey chose JVM as the platform of choice when he invented Clojure. It's community developed set of tools and documentation grew around the JVM (Leiningen, for example). From the above statements, can I say that *the JVM will always likely, remain the primary Clojure implementation* ? Thank 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: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback
Hi I'd change your fizzy function so it returns a string instead of printing it. This way it will be pure function and more functional-like. In doseq you'll need (printlng (fuzzy x)) instead of (fuzzy x). Nikita Beloglazov On Saturday, December 29, 2012 3:35:38 PM UTC+3, Sean Chalmers wrote: Greetings all! I'm just starting out in the so far wonderful world of Clojure and to help me get started I had a crack at one of my favourites, the FizzBuzz program. For anyone that isn't familiar with FizzBuzz, it is designed to count from 1 to N and take the following actions when certain conditions are met: - When the remainder of i divided by 3 is 0 print Fizz - When the remainder of i divided by 5 is 0 print Buzz - When both the former are true of i print FizzBuzz I crafted the following as a solution and I would really appreciate some more experienced Clojurians casting their eye over it and letting me know if what I've done is in the style and spirit of Clojure. Also this is my first functional language so any feedback on that would be awesome too. :) I'm aware it's only a tnsy piece of code so not terribly indicative of the hilarity that might ensue on a larger project but all the same. Enough of my blathering here is the meaty bit: (defn zero-remainder? [x y] (zero? (rem x y))) (defn fizzy [x] (let [fizz (zero-remainder? x 3) buzz (zero-remainder? x 5)] (if (and fizz buzz) (println FizzBuzz: x) (if buzz (println Buzz: x) (if fizz (println Fizz: x)) (doseq [x (range 1 25)] (fizzy x)) -- 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] Dire, Erlang-style error handling
Hey,
I really like the idea of pulling out exception handling from the function
bodies. The try catch form has always bugged me a little bit.
One thing that worries me though. While this is fine for examples where you
simply log the exception and move on, what if you need to do something more
complicated with the actual data? Say for example you need to queue/trigger
a retry, you no longer have your local bindings to work with so you'd have
to go back to a normal try/catch (disclaimer - didn't read the paper, just
going off the code and your comments)
Couple of thoughts on the code:
If you want to attach the error handlers to a particular function var
(task), why not alter-meta and add the handler function there rather than
maintaining a separate atom? Given that the deftask is pretty much
redundant anyway, I don't really see the point in making the distinction.
Plus I think your current code is dropping namespaces, causing potential
future explosions?
I'd be tempted to make a supervise function which simply takes a handler
map and do away with the macros altogether, you can still def handlers at
the top level if you want to re-use them, but you could also merge sets of
handlers if you wanted, or pass in handlers which have some idea of what
task you're supervising because they have been declared in the same lexical
scope, e.g.
(let [currenturl ...]
(supervise {ConnectionError (fn [e] (queue-retry! currenturl))
NotFoundError (fn [e] (log failed: currenturl
(.getMessage e))}
fetch-url currenturl :timeout 10))
or your example would look like:
(defn divider [a b]
(/ a b))
(def div-zero-handler
{ArithmeticException (fn [e] (println Cannot divide by zero))})
(def npe-handler
{NullPointerException (fn [e] (println ...))})
(def supervised-divider (partial divider (merge div-zero-handler
npe-handler)))
(supervised-divider 10 0)...
Which I would argue is a lot more idiomatic and flexible. I think macros
are overkill and unnecessary complexity here, you just need a supervise
function which takes responsibility for catching errors and lets you re-use
handlers
Adam
On Friday, December 28, 2012 7:14:34 PM UTC, Michael Drogalis wrote:
Hey folks,
After watching The Language of the System and being directed to Joe
Armstrong's paper on error handling, I concurred that his approach is
fantastic. I really wanted the same thing for more rudimentary operations,
like file handling. So I wrote Dire
https://github.com/MichaelDrogalis/dire
The pros are of this are that error handling code is removed from
application logic and it is not order complected.
The cons are that tasks are not as strongly isolated as they are in
Erlang. Also, because it is so simple (16 lines),
there's no way for a supervisor to restart a child task. (Yet, I guess.
Ideas?)
Can such a thing be useful in a non-distributed environment? Or does this
look like a hassle to use?
--
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: reduce-kv incompatible with subvec
I haven't taken the time to check whether that is correct or not, but the
answer that is most likely the truth is no one has yet had the time or
interest to add such a thing yet.
You are welcome to create a ticket describing the problem, and attach a patch
to it that fixes the issue, and see if it will be accepted as a change to
Clojure. To have a patch accepted you will need to sign a Clojure
Contributor's Agreement first [1], and [2] describes the mechanics of creating
patches.
[1] http://clojure.org/contributing
[2] http://dev.clojure.org/display/design/JIRA+workflow
Andy
On Dec 28, 2012, at 5:36 PM, Alan Busby wrote:
Just curious why something like the following wouldn't be part of subvector?
public Object kvreduce(IFn f, Object init){
for(int i=0;i(end - start);i++){
init = f.invoke(init,i,v.nth(start+i));
return init;
}
On Fri, Dec 28, 2012 at 11:23 PM, Andy Fingerhut andy.finger...@gmail.com
wrote:
I am not saying that one would *have* to give up O(1) subvec in order to
support other operations.
I am guessing, without having done a thorough analysis, that an O(log n)
subvec based on RRB Trees would make most/all operations on subvec's just
fall out fairly naturally, rather than having to be written as special cases.
Andy
On Dec 27, 2012, at 8:54 PM, Alan Busby wrote:
I'm confused why we'd need to give up O(1) just to support something like
reduce-kv on subvectors.
Isn't the implementation of subvector just a wrapper around the original
vector along with a start and end value?
Current source here;
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentVector.java
I apologize if I'm missing something key here.
On Fri, Dec 28, 2012 at 3:18 AM, Andy Fingerhut andy.finger...@gmail.com
wrote:
http://dev.clojure.org/jira/browse/CLJ-1082
--
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
--
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: Will the JVM will always likely, remain the primary Clojure implementation ?
If you don't get a flood of responses, I think it is because in this thread and the one linked earlier that Leon Adler started, several different people have explained evidence that Clojure on the JVM has had active development for five years, it is open source, and no one knows of any evidence that this will change any time in the future. That isn't the same as saying will remain, but it is the best anyone can give you that is based on evidence and reason, rather than some other dubious methods. If you believe another language will give you better assurances than that about its future target/platform, I don't see how you came to that conclusion, unless it is by making up conclusions out of thin air. Andy On Dec 29, 2012, at 2:58 AM, Leon Adler wrote: That's unforeseeable because, that represents a very long time. Having said that, this statement deserves a resay... The JVM will remain the primary target/platform for Clojure, while Oracle remains good i.e. it doesn't get Barmy. What say the other people? On Saturday, December 29, 2012 3:53:12 PM UTC+5:30, Sukh Singh wrote: Having read the posts all over again, can I say that the JVM will remain the primary target/platform for Clojure, while Oracle remains good i.e. it doesn't get Barmy ? Isn't that unforeseeable? On Thursday, December 27, 2012 4:56:52 PM UTC+5:30, Sukh Singh wrote: Hi, I have noticed that this question is randomly appearing in many minds, and it is frequently being asked, though there is no apparent reason on why it is asked :/ or maybe people are unable to pen down the exact reasons, and sad to say, even myself. There are reasons for which I ask this question - People (Majority) tend to stick with the primary implementations of certain multi-implementation software. And in the case of Clojure, the JVM implementation is the primary implementation now. Having a primary implementation in case of BDFL lead software helps as a glue in the community. For example , CPython is the primary python implementation, even if there is an existance of IronPython or JPython. The doubts of many, including me, will be cleared by an abstract answer... That 'many' also include the companies adopting something new, in this particular case, adopting clojure QUESTION Rich Hickey chose JVM as the platform of choice when he invented Clojure. It's community developed set of tools and documentation grew around the JVM (Leiningen, for example). From the above statements, can I say that the JVM will always likely, remain the primary Clojure implementation ? Thank 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 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 mug templates
On Saturday, December 29, 2012 8:54:44 AM UTC-5, Nikita Beloglazov wrote: Hi I taught small clojure class at my university this semester. At the end of the class I printed clojure mugs for my students with their names. Here I want to share small javascript/html page I used to generate templates for mugs. I hope someone find it useful. Page: http://nbeloglazov.github.com/clojure-mug-template/ GitHub repo: https://github.com/nbeloglazov/clojure-mug-template/ Neat. Though, what is `slice`? Oh, and I don't see `comp` in there! Also, maybe replace noir with lib-noir now. ---John -- 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] Dire, Erlang-style error handling
Thanks for the awesome feedback.
On Saturday, December 29, 2012 9:57:56 AM UTC-5, Adam Clements wrote:
Hey,
I really like the idea of pulling out exception handling from the function
bodies. The try catch form has always bugged me a little bit.
One thing that worries me though. While this is fine for examples where
you simply log the exception and move on, what if you need to do something
more complicated with the actual data? Say for example you need to
queue/trigger a retry, you no longer have your local bindings to work with
so you'd have to go back to a normal try/catch (disclaimer - didn't read
the paper, just going off the code and your comments)
I agree. There's certainly cases where the handler will want to restart the
task and need access to the original bindings. I'll tinker around with a
clean way to do this. Open for suggestions.
Couple of thoughts on the code:
If you want to attach the error handlers to a particular function var
(task), why not alter-meta and add the handler function there rather than
maintaining a separate atom? Given that the deftask is pretty much
redundant anyway, I don't really see the point in making the distinction.
Plus I think your current code is dropping namespaces, causing potential
future explosions?
Correct, deftask is redundant. I wanted more language to be able to talk
about what a task is though. This might not be necessary due to what you
said below this. Also, can you give an example of dropping namespaces? I
don't think I see where this happens, but I'm sure it's present.
I'd be tempted to make a supervise function which simply takes a handler
map and do away with the macros altogether, you can still def handlers at
the top level if you want to re-use them, but you could also merge sets of
handlers if you wanted, or pass in handlers which have some idea of what
task you're supervising because they have been declared in the same lexical
scope, e.g.
(let [currenturl ...]
(supervise {ConnectionError (fn [e] (queue-retry! currenturl))
NotFoundError (fn [e] (log failed: currenturl
(.getMessage e))}
fetch-url currenturl :timeout 10))
or your example would look like:
(defn divider [a b]
(/ a b))
(def div-zero-handler
{ArithmeticException (fn [e] (println Cannot divide by zero))})
(def npe-handler
{NullPointerException (fn [e] (println ...))})
(def supervised-divider (partial divider (merge div-zero-handler
npe-handler)))
(supervised-divider 10 0)...
Which I would argue is a lot more idiomatic and flexible. I think macros
are overkill and unnecessary complexity here, you just need a supervise
function which takes responsibility for catching errors and lets you re-use
handlers
Adam
Joe's paper (for reference
http://www.erlang.org/download/armstrong_thesis_2003.pdf), in section 4.3.2
on page 106 states that the goals are:
1. *Clean separation of issues*.
Dire achieves this by total separation of worker logic and supervisor
logic. (IE let it crash)
2. *Special processes only for error handling*.
Dire does not have this. Erlang processes aren't OS processes, but they are
strongly isolated. These handlers that we set up in Dire have to be more
resilient. I'm not sure how to do this at the moment.
3. *Workers can be run on different physical machines*.
Dire does not have this. Drawing on more knowledge from the Language of the
System, what if we put queues between supervisors and workers? Is this
worth it? I'm curious if you guys think it's a good idea for this
environment.
4. *Error processing code becomes generic*.
To some degree Dire has this. The functions bound to defhandler can be
reused.
I'm not comfortable with axing defhandler because I wanted this to feel
like multimethods. I think it's a good idea for users of the supervise
function to call their worker/task function and away it goes. If a new
handler is defined, the map passed to supervise has to be modified, which
violates the Open/Closed principle. That said, if you fork it and give your
approach a try, I'm sure we can further this idea in some respective.
On Friday, December 28, 2012 7:14:34 PM UTC, Michael Drogalis wrote:
Hey folks,
After watching The Language of the System and being directed to Joe
Armstrong's paper on error handling, I concurred that his approach is
fantastic. I really wanted the same thing for more rudimentary operations,
like file handling. So I wrote Dire
https://github.com/MichaelDrogalis/dire
The pros are of this are that error handling code is removed from
application logic and it is not order complected.
The cons are that tasks are not as strongly isolated as they are in
Erlang. Also, because it is so simple (16 lines),
there's no way for a supervisor to restart a child task. (Yet, I guess.
Ideas?)
Can such a thing be useful in a non-distributed environment? Or does this
look like a hassle to
Re: [ANN] Dire, Erlang-style error handling
On Sat, Dec 29, 2012 at 10:13 AM, Michael Drogalis madrush...@gmail.com wrote: On Saturday, December 29, 2012 9:57:56 AM UTC-5, Adam Clements wrote: One thing that worries me though. While this is fine for examples where you simply log the exception and move on, what if you need to do something more complicated with the actual data? Say for example you need to queue/trigger a retry, you no longer have your local bindings to work with so you'd have to go back to a normal try/catch (disclaimer - didn't read the paper, just going off the code and your comments) I agree. There's certainly cases where the handler will want to restart the task and need access to the original bindings. I'll tinker around with a clean way to do this. Open for suggestions. Isn't this what Common Lisp's condition system allowed? (And wasn't there a condition-like library for Clojure?) -- 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
Re: ClojureCLR 1.5.0 RC 1
The executables and DLLs under the regular binary download will work just fine under Mono. On Saturday, December 29, 2012 2:06:31 AM UTC-6, Shantanu Kumar wrote: On Thursday, 27 December 2012 23:15:04 UTC+5:30, dmiller wrote: ClojureCLR is caught up with all changes to ClojureJVM up to 1.5.0-RC1. This includes all relevant bug fixes, the reducers library, reader literal improvements, new threading macros and other goodness. See changes.md. The only change not yet implemented is the new reliance on the test.generative library. That's going to wait until there are some improvements in the build and project management process. You won't notice the difference. One change specific to ClojureCLR: building/running under Mono is now supported. That's fantastic! Is there a binary download link you'd like to share? Shantanu -- 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 mug templates
This is pretty cool, and a good idea for building screensaver on that theme. Shantanu On Dec 29, 6:54 pm, Nikita Beloglazov nikelandj...@gmail.com wrote: Hi I taught small clojure class at my university this semester. At the end of the class I printed clojure mugs for my students with their names. Here I want to share small javascript/html page I used to generate templates for mugs. I hope someone find it useful. Page:http://nbeloglazov.github.com/clojure-mug-template/ GitHub repo:https://github.com/nbeloglazov/clojure-mug-template/ You can clone repo and open index.html from local copy. Thank you, Nikita Beloglazov -- 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] Dire, Erlang-style error handling
I've never seen that before, Ben. Can you link me? Just pushed version 0.1.1 with these suggestions: - Tasks are now simple functions, not macros - Using metadata to keep track of handlers rather than an atom. - Fixed namespace collision issue - Pass original arguments of task function to error handler Any way we can make this better? On Saturday, December 29, 2012 1:22:30 PM UTC-5, Ben wrote: On Sat, Dec 29, 2012 at 10:13 AM, Michael Drogalis madru...@gmail.comjavascript: wrote: On Saturday, December 29, 2012 9:57:56 AM UTC-5, Adam Clements wrote: One thing that worries me though. While this is fine for examples where you simply log the exception and move on, what if you need to do something more complicated with the actual data? Say for example you need to queue/trigger a retry, you no longer have your local bindings to work with so you'd have to go back to a normal try/catch (disclaimer - didn't read the paper, just going off the code and your comments) I agree. There's certainly cases where the handler will want to restart the task and need access to the original bindings. I'll tinker around with a clean way to do this. Open for suggestions. Isn't this what Common Lisp's condition system allowed? (And wasn't there a condition-like library for Clojure?) -- 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
Re: [ANN] Dire, Erlang-style error handling
On Sat, Dec 29, 2012 at 12:44 PM, Michael Drogalis madrush...@gmail.com wrote: I've never seen that before, Ben. Can you link me? Overview of CL conditions/restarts here: http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html The Clojure lib was clojure.contrib.error-kit (http://richhickey.github.com/clojure-contrib/error-kit-api.html), which has been superseded by slingshot---but I think that slingshot does not aim to provide conditions and restarts. Just pushed version 0.1.1 with these suggestions: - Tasks are now simple functions, not macros - Using metadata to keep track of handlers rather than an atom. - Fixed namespace collision issue - Pass original arguments of task function to error handler Any way we can make this better? On Saturday, December 29, 2012 1:22:30 PM UTC-5, Ben wrote: On Sat, Dec 29, 2012 at 10:13 AM, Michael Drogalis madru...@gmail.com wrote: On Saturday, December 29, 2012 9:57:56 AM UTC-5, Adam Clements wrote: One thing that worries me though. While this is fine for examples where you simply log the exception and move on, what if you need to do something more complicated with the actual data? Say for example you need to queue/trigger a retry, you no longer have your local bindings to work with so you'd have to go back to a normal try/catch (disclaimer - didn't read the paper, just going off the code and your comments) I agree. There's certainly cases where the handler will want to restart the task and need access to the original bindings. I'll tinker around with a clean way to do this. Open for suggestions. Isn't this what Common Lisp's condition system allowed? (And wasn't there a condition-like library for Clojure?) -- 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 -- 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
Re: Clojure mug templates
Thank you, John. I've fixed this. Nikita On Sat, Dec 29, 2012 at 8:21 PM, John Gabriele jmg3...@gmail.com wrote: On Saturday, December 29, 2012 8:54:44 AM UTC-5, Nikita Beloglazov wrote: Hi I taught small clojure class at my university this semester. At the end of the class I printed clojure mugs for my students with their names. Here I want to share small javascript/html page I used to generate templates for mugs. I hope someone find it useful. Page: http://nbeloglazov.github.com/**clojure-mug-template/http://nbeloglazov.github.com/clojure-mug-template/ GitHub repo: https://github.com/**nbeloglazov/clojure-mug-**template/https://github.com/nbeloglazov/clojure-mug-template/ Neat. Though, what is `slice`? Oh, and I don't see `comp` in there! Also, maybe replace noir with lib-noir now. ---John -- 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: [ANN] Dire, Erlang-style error handling
The CL article is really interesting, thanks. What do you think of the idea of using Slingshot's try+ within Dire? On Saturday, December 29, 2012 3:55:13 PM UTC-5, Ben wrote: On Sat, Dec 29, 2012 at 12:44 PM, Michael Drogalis madru...@gmail.comjavascript: wrote: I've never seen that before, Ben. Can you link me? Overview of CL conditions/restarts here: http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html The Clojure lib was clojure.contrib.error-kit (http://richhickey.github.com/clojure-contrib/error-kit-api.html), which has been superseded by slingshot---but I think that slingshot does not aim to provide conditions and restarts. Just pushed version 0.1.1 with these suggestions: - Tasks are now simple functions, not macros - Using metadata to keep track of handlers rather than an atom. - Fixed namespace collision issue - Pass original arguments of task function to error handler Any way we can make this better? On Saturday, December 29, 2012 1:22:30 PM UTC-5, Ben wrote: On Sat, Dec 29, 2012 at 10:13 AM, Michael Drogalis madru...@gmail.com wrote: On Saturday, December 29, 2012 9:57:56 AM UTC-5, Adam Clements wrote: One thing that worries me though. While this is fine for examples where you simply log the exception and move on, what if you need to do something more complicated with the actual data? Say for example you need to queue/trigger a retry, you no longer have your local bindings to work with so you'd have to go back to a normal try/catch (disclaimer - didn't read the paper, just going off the code and your comments) I agree. There's certainly cases where the handler will want to restart the task and need access to the original bindings. I'll tinker around with a clean way to do this. Open for suggestions. Isn't this what Common Lisp's condition system allowed? (And wasn't there a condition-like library for Clojure?) -- 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 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 -- 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
Re: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback
Yay! Thanks for the feedback everyone. I originally had it as a 'cond' but because I was using 'println' directly in my fizzy function I was getting on 15 for example fizzbuzz, buzz, fizz but changing it to more pure function would probably deal with that. I'll have a play with 'when' as well, hadn't tried that one yet. Thanks again and I look forward to showing off some Clojure creations in the wild soon. On Saturday, 29 December 2012 22:35:38 UTC+10, Sean Chalmers wrote: Greetings all! I'm just starting out in the so far wonderful world of Clojure and to help me get started I had a crack at one of my favourites, the FizzBuzz program. For anyone that isn't familiar with FizzBuzz, it is designed to count from 1 to N and take the following actions when certain conditions are met: - When the remainder of i divided by 3 is 0 print Fizz - When the remainder of i divided by 5 is 0 print Buzz - When both the former are true of i print FizzBuzz I crafted the following as a solution and I would really appreciate some more experienced Clojurians casting their eye over it and letting me know if what I've done is in the style and spirit of Clojure. Also this is my first functional language so any feedback on that would be awesome too. :) I'm aware it's only a tnsy piece of code so not terribly indicative of the hilarity that might ensue on a larger project but all the same. Enough of my blathering here is the meaty bit: (defn zero-remainder? [x y] (zero? (rem x y))) (defn fizzy [x] (let [fizz (zero-remainder? x 3) buzz (zero-remainder? x 5)] (if (and fizz buzz) (println FizzBuzz: x) (if buzz (println Buzz: x) (if fizz (println Fizz: x)) (doseq [x (range 1 25)] (fizzy x)) -- 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
Advice on Clojure, Emacs, Lein setup on Fedora
Hi I am running F18 and wanting to setup and get goin in Clojure Just wanted to put a summary of the things I have got so far in case I have missed something easy obvious that will get me going quicker. *Fedora* To setup on Fedora I have installed these packages(emacs already installed) clojure-contrib.noarch clojure.noarch leiningen.noarch *Emacs(using ELPA and Marmalade)* Install clojure-mode slime slime-repl swank-clojure M-x slime # to start and install dependencies. *Lenigen -lein* Installed via package manager, how do I use with Emacs? *General Question* * * 1. Is there anything I should use in .emacs for syntax highlighting and clojure project support? 2. Is there a code linter/tidy for clojure and/or emacs? *Resources* Some resources I have found. Leningen - https://github.com/technomancy/leiningen/blob/master/README.md Volkman Tutorial - http://java.ociweb.com/mark/clojure/article.html#GettingStarted Tutorial - http://pramode.net/clojure/2010/04/29/getting-started-with-clojure/ Fedora Clojure Project docs - http://fedoraproject.org/wiki/Features/Clojure Full DisClojure - http://vimeo.com/channels/fulldisclojure Clojure Docs - http://clojure.org/documentation Codeschool Clojure - http://www.codeschool.com/code_tv/getting-started-with-clojure-part-1 Learn Clojure - http://learn-clojure.com/clojure_tutorials.html Clojure Links (2009) - http://mattsears.com/articles/2009/06/06/20-clojure-links-to-get-you-up-to-speed Is there anything I am missing or could do better to make sure I get running the quickest? Thanks Sayth * * -- 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] Hosted findfn
I love Anthony Grimes's (et al) findfn https://github.com/Raynes/findfn library, but it requires some local setup (mainly the JVM security config for clojail), so I decided to host it on Heroku. Features: - Access to findfn from any computer with no setup. - If your function has two arguments, tries the original and reversed orderings (searching for [1 2 3] , = 1, 2, 3 returns join, even though the args are backwards). - For each function, includes the docstring, namespace, the version it was added, and whether or not it has been deprecated. - Links each function to clojuredocs.org Limitations/Issues: - Non-existent error handling (it just gets stuck on the searching screen forever if any problem happens); this definitely needs to be fixed soon. - It's slow. - Only searches different orderings if you have exactly two args. I originally had it searching up to 5 permutations of your args, but it was exceeding Heroku's 30-second timeout. - Doesn't support find-arg. - Only searches clojure.core, clojure.string, and clojure.set. - Not on github yet. Let me know if you run into any issues or have any cool ideas for this. (I emailed Anthony to make sure he was fine with me using the findfn name and that the attribution was good enough) -- 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
Clarification on setting up Clojure, Lein and Emacs on fedora
Just want to make sure I get this right. I am running F18 and am setting up clojure. These would be the packages to install, correct? clojure.noarch clojure-contrib.noarch leiningen.noarch emacs-slime.noarch *For slime and the emacs repl* clojure-mode, slime, slime-repl and swank-clojure restart M-X to install the clojure REPL. *For lein - *better then maven, yes? Just install the package and then use on command line. But how in Emacs? *Emacs* Is there anything I should be putting in my .emacs to get project and syntax support and the ability to send select text to a REPL? *General Question* Is there a code linter beautifier? *Resources* Lenigen - https://github.com/technomancy/leiningen/blob/master/README.md Tutorial - http://www.learningclojure.com/ Volkmann - http://java.ociweb.com/mark/clojure/article.html#GettingStarted Tutorial - http://pramode.net/clojure/2010/04/29/getting-started-with-clojure/ Fedora Clojure Docs - http://fedoraproject.org/wiki/Features/Clojure Anything advice on the above or something obvious I have missed that will get me going quicker? Thank You Sayth -- 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
cljs-clj interop
Hi all, I'm toying with a way to use Clojure objects from a Rhino-based ClojureScript environment (https://github.com/harto/rhino-bridge). I've been able to export a Clojure function into the ClojureScript environment without too much difficulty. Ideally, I'd like to be able to call that function as if it were a regular ClojureScript function. I was hoping I could do something like: (extend-type js/Packages.clojure.lang.IFn IFn (-invoke [this] (.invoke this)) (-invoke [this a] (.invoke this a)) ;; etc ) However, this yields an error that I don't quite understand: java.lang.UnsupportedOperationException: nth not supported on this type: Symbol at clojure.lang.RT.nthFrom(RT.java:846) at clojure.lang.RT.nth(RT.java:796) at cljs.core$extend_type$assign_impls__7365$fn__7377$adapt_params__7380.invoke(core.clj:486) at clojure.core$map$fn__4087.invoke(core.clj:2434) In fact, I'm not sure this will work at all, since (type) doesn't appear to work with non-native JS objects. Is the extend-type method feasible? Cheers, Stuart -- 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: cljs-clj interop
I think you've just formatted your code incorrectly. Did you try something like this? (extend-type js/Packages.clojure.lang.IFn IFn (-invoke ([this] (.invoke this)) ([this a] (.invoke this a))) ) On Sat, Dec 29, 2012 at 8:22 PM, Stuart Campbell stu...@harto.org wrote: Hi all, I'm toying with a way to use Clojure objects from a Rhino-based ClojureScript environment (https://github.com/harto/rhino-bridge). I've been able to export a Clojure function into the ClojureScript environment without too much difficulty. Ideally, I'd like to be able to call that function as if it were a regular ClojureScript function. I was hoping I could do something like: (extend-type js/Packages.clojure.lang.IFn IFn (-invoke [this] (.invoke this)) (-invoke [this a] (.invoke this a)) ;; etc ) However, this yields an error that I don't quite understand: java.lang.UnsupportedOperationException: nth not supported on this type: Symbol at clojure.lang.RT.nthFrom(RT.java:846) at clojure.lang.RT.nth(RT.java:796) at cljs.core$extend_type$assign_impls__7365$fn__7377$adapt_params__7380.invoke(core.clj:486) at clojure.core$map$fn__4087.invoke(core.clj:2434) In fact, I'm not sure this will work at all, since (type) doesn't appear to work with non-native JS objects. Is the extend-type method feasible? Cheers, Stuart -- 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: Clarification on setting up Clojure, Lein and Emacs on fedora
If you have a recent (24) Emacs, use M-x package-install and install clojure-mode and nrepl. nrepl is the successor-in-spirit of slime, as many people consider slime as deprecated. When you have access to leiningen 2 (strongly recommended), the whole setup simplifies to: 1) Install leiningen 2 Emacs 24 2) In Emacs: Add Marmelade repository 3) In Emacs: M-x package-install RET nrepl RET 4) nrepl-jack-in On Sun, Dec 30, 2012 at 12:47 AM, Sayth Renshaw flebber.c...@gmail.com wrote: Just want to make sure I get this right. I am running F18 and am setting up clojure. These would be the packages to install, correct? clojure.noarch clojure-contrib.noarch leiningen.noarch emacs-slime.noarch For slime and the emacs repl clojure-mode, slime, slime-repl and swank-clojure restart M-X to install the clojure REPL. For lein - better then maven, yes? Just install the package and then use on command line. But how in Emacs? Emacs Is there anything I should be putting in my .emacs to get project and syntax support and the ability to send select text to a REPL? General Question Is there a code linter beautifier? Resources Lenigen - https://github.com/technomancy/leiningen/blob/master/README.md Tutorial - http://www.learningclojure.com/ Volkmann - http://java.ociweb.com/mark/clojure/article.html#GettingStarted Tutorial - http://pramode.net/clojure/2010/04/29/getting-started-with-clojure/ Fedora Clojure Docs - http://fedoraproject.org/wiki/Features/Clojure Anything advice on the above or something obvious I have missed that will get me going quicker? Thank You Sayth -- 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: Trouble calling Dojo grid constructor from ClojureScript
From what I can tell, dojo is testing an argument to see whether it has a
method named call. dojo seems to be assuming that if such a method
exists, then the argument will not be a string.
Then clojurescript seems to be assigning a function named call to the
String prototype. And so these two libraries conflict.
I am unsure whether either library is completely to blame. However it seems
fairly clear that dojo does not intend to invoke call on a string.
Changing dojo/on.js, line 83, to
if(type.call (!type instanceof String)){
does fix the problem. I'll check with the dojo folks on making a change
along these lines unless someone can suggest a change to clojurescript.
-Patrick
On Wednesday, November 28, 2012 9:15:11 PM UTC-8, Brian Nelson wrote:
ok. I've had some time to look into this now and have figured out a few
things.
1. This is not due to calling the DGrid constructor from clojurescript. It
occurs even when I call the DGrid constructor from straight javascript
code. So it doesn't have to do with the clojurescript code calling the
constructor.
2. The error goes away if I don't require cljs.core. If cljs.core is
required then the grid constructor ends up calling back into some code in
cljs.core, which is where the error occurs.
So I'm a little further down the road but still don't know exactly why
doing a goog.require(cljs.core) causes cljs.core to receive events from
the DGrid constructor. Digging in with my javascript debugger and will
update this as I find out more information.
On Monday, November 19, 2012 11:15:54 PM UTC-6, Brian Nelson wrote:
Hi,
I'm brand new to ClojureScript and have been trying to get myself
familiarized with it's javascript interop capabilities by implementing
the Dojo toolkit tutorials. I've successfully implemented several of
the tutorials, but now I've run into something that I can't figure out
and am looking for someone to point me in the right direction.
I am calling the DGrid(Dojo grid) constructor using the function
maingrid
(ns couchadmin.core
(:use [jayq.util :only [clj-js]])
(:require [clojure.browser.repl :as repl]))
(defn greet [dom fx]
(let [element (.byId dom greetingcljs)]
(set! (. element -innerHTML) Hello from Dojo using
ClojureScript)
(.play (.slideTo fx (clj-js {:top 200 :left 200 :node
element})
(defn maingrid [dom grd]
(do
(grd. (clj-js {:columns (clj-js {:first First Name})}) grid)
(js/alert hello world)))
(defn ^:export main []
(comment (repl/connect http://localhost:9000/repl;))
(comment (js/require (array dojo/dom dojo/fx dojo/domReady!)
greet))
(js/require (array dojo/dom dgrid/Grid dojo/domReady!)
maingrid))
When the page is loaded the grid is constructed, but afterwards I see
the following javascript exception
Uncaught Error: No protocol method ILookup.-lookup defined for
type object: [object HTMLDivElement]
I'm wondering what this message is indicating. Did I call the
constructor incorrectly? Is this an incompatibility with Dojo? Do I
need to implement ILookup somehow? Any help would be greatly
appreciated.
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: Trouble calling Dojo grid constructor from ClojureScript
Yes this is known problem w/ ClojureScript that could be solved if/when we
get proper Keywords/Symbol types.
David
On Sat, Dec 29, 2012 at 8:46 PM, Patrick Logan patrickdlo...@gmail.comwrote:
From what I can tell, dojo is testing an argument to see whether it has a
method named call. dojo seems to be assuming that if such a method
exists, then the argument will not be a string.
Then clojurescript seems to be assigning a function named call to the
String prototype. And so these two libraries conflict.
I am unsure whether either library is completely to blame. However it
seems fairly clear that dojo does not intend to invoke call on a string.
Changing dojo/on.js, line 83, to
if(type.call (!type instanceof String)){
does fix the problem. I'll check with the dojo folks on making a change
along these lines unless someone can suggest a change to clojurescript.
-Patrick
On Wednesday, November 28, 2012 9:15:11 PM UTC-8, Brian Nelson wrote:
ok. I've had some time to look into this now and have figured out a few
things.
1. This is not due to calling the DGrid constructor from clojurescript.
It occurs even when I call the DGrid constructor from straight javascript
code. So it doesn't have to do with the clojurescript code calling the
constructor.
2. The error goes away if I don't require cljs.core. If cljs.core is
required then the grid constructor ends up calling back into some code in
cljs.core, which is where the error occurs.
So I'm a little further down the road but still don't know exactly why
doing a goog.require(cljs.core) causes cljs.core to receive events from
the DGrid constructor. Digging in with my javascript debugger and will
update this as I find out more information.
On Monday, November 19, 2012 11:15:54 PM UTC-6, Brian Nelson wrote:
Hi,
I'm brand new to ClojureScript and have been trying to get myself
familiarized with it's javascript interop capabilities by implementing
the Dojo toolkit tutorials. I've successfully implemented several of
the tutorials, but now I've run into something that I can't figure out
and am looking for someone to point me in the right direction.
I am calling the DGrid(Dojo grid) constructor using the function
maingrid
(ns couchadmin.core
(:use [jayq.util :only [clj-js]])
(:require [clojure.browser.repl :as repl]))
(defn greet [dom fx]
(let [element (.byId dom greetingcljs)]
(set! (. element -innerHTML) Hello from Dojo using
ClojureScript)
(.play (.slideTo fx (clj-js {:top 200 :left 200 :node
element})
(defn maingrid [dom grd]
(do
(grd. (clj-js {:columns (clj-js {:first First Name})}) grid)
(js/alert hello world)))
(defn ^:export main []
(comment (repl/connect http://localhost:9000/repl;))
(comment (js/require (array dojo/dom dojo/fx dojo/domReady!)
greet))
(js/require (array dojo/dom dgrid/Grid dojo/domReady!)
maingrid))
When the page is loaded the grid is constructed, but afterwards I see
the following javascript exception
Uncaught Error: No protocol method ILookup.-lookup defined for
type object: [object HTMLDivElement]
I'm wondering what this message is indicating. Did I call the
constructor incorrectly? Is this an incompatibility with Dojo? Do I
need to implement ILookup somehow? Any help would be greatly
appreciated.
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
--
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: Trouble calling Dojo grid constructor from ClojureScript
I sent a note to the dojo list, so they're aware of the situation.
Meanwhile it's an easy enough work-around to avoid the problem.
-Patrick
On Saturday, December 29, 2012 5:51:32 PM UTC-8, David Nolen wrote:
Yes this is known problem w/ ClojureScript that could be solved if/when we
get proper Keywords/Symbol types.
David
On Sat, Dec 29, 2012 at 8:46 PM, Patrick Logan
patric...@gmail.comjavascript:
wrote:
From what I can tell, dojo is testing an argument to see whether it has a
method named call. dojo seems to be assuming that if such a method
exists, then the argument will not be a string.
Then clojurescript seems to be assigning a function named call to the
String prototype. And so these two libraries conflict.
I am unsure whether either library is completely to blame. However it
seems fairly clear that dojo does not intend to invoke call on a string.
Changing dojo/on.js, line 83, to
if(type.call (!type instanceof String)){
does fix the problem. I'll check with the dojo folks on making a change
along these lines unless someone can suggest a change to clojurescript.
-Patrick
On Wednesday, November 28, 2012 9:15:11 PM UTC-8, Brian Nelson wrote:
ok. I've had some time to look into this now and have figured out a few
things.
1. This is not due to calling the DGrid constructor from clojurescript.
It occurs even when I call the DGrid constructor from straight javascript
code. So it doesn't have to do with the clojurescript code calling the
constructor.
2. The error goes away if I don't require cljs.core. If cljs.core is
required then the grid constructor ends up calling back into some code in
cljs.core, which is where the error occurs.
So I'm a little further down the road but still don't know exactly why
doing a goog.require(cljs.core) causes cljs.core to receive events from
the DGrid constructor. Digging in with my javascript debugger and will
update this as I find out more information.
On Monday, November 19, 2012 11:15:54 PM UTC-6, Brian Nelson wrote:
Hi,
I'm brand new to ClojureScript and have been trying to get myself
familiarized with it's javascript interop capabilities by implementing
the Dojo toolkit tutorials. I've successfully implemented several of
the tutorials, but now I've run into something that I can't figure out
and am looking for someone to point me in the right direction.
I am calling the DGrid(Dojo grid) constructor using the function
maingrid
(ns couchadmin.core
(:use [jayq.util :only [clj-js]])
(:require [clojure.browser.repl :as repl]))
(defn greet [dom fx]
(let [element (.byId dom greetingcljs)]
(set! (. element -innerHTML) Hello from Dojo using
ClojureScript)
(.play (.slideTo fx (clj-js {:top 200 :left 200 :node
element})
(defn maingrid [dom grd]
(do
(grd. (clj-js {:columns (clj-js {:first First Name})}) grid)
(js/alert hello world)))
(defn ^:export main []
(comment (repl/connect http://localhost:9000/repl;))
(comment (js/require (array dojo/dom dojo/fx dojo/domReady!)
greet))
(js/require (array dojo/dom dgrid/Grid dojo/domReady!)
maingrid))
When the page is loaded the grid is constructed, but afterwards I see
the following javascript exception
Uncaught Error: No protocol method ILookup.-lookup defined for
type object: [object HTMLDivElement]
I'm wondering what this message is indicating. Did I call the
constructor incorrectly? Is this an incompatibility with Dojo? Do I
need to implement ILookup somehow? Any help would be greatly
appreciated.
Brian
--
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 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
Emacs launching 2 java processes
Hi, I'm using emacs with inferior-lisp setup to use lein repl. Everything works fine, but when I start the repl, I see two java.exe processes on my windows task manager. Is this normal behavior? Why two java processes not one are needed? -- 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: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback
On Saturday, December 29, 2012 5:15:49 PM UTC-5, Sean Chalmers wrote: ... but changing it to more pure function would probably deal with that. Another benefit of pure functions is that they're easier to test. I'll have a play with 'when' as well, hadn't tried that one yet. `when` provides an implicit `do`, so I generally try to only use it when I want side-effects. (Other side-effecty forms include `do`, `doseq`, `dotimes` and `when-not`.) ---John -- 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: Clarification on setting up Clojure, Lein and Emacs on fedora
Sayth, Not sure I follow everything in your post, but here are some tips: 1. You don't need to install Clojure itself. Leiningen takes care of that for you. See 2. Make sure you install Emacs 24. I don't know what the Fedora incantations are for this. 3. Once you've got Emacs 24 installed, add this to your ~/.emacs file: ~~~elisp (require 'package) (add-to-list 'package-archives '(marmalade . http://marmalade-repo.org/packages/;)) (package-initialize) ~~~ and then you can have Emacs install clojure-mode (and any other Emacs packages you desire) via M-x package-install RET the-package-name (for example, clojure-mode). 4. To get a Clojure repl in Emacs, my understanding is that slime is no longer the state of the art, and that you instead want to use nrepl.el. Some info regarding that at https://github.com/technomancy/clojure-mode (see the doc directory and wiki there too). As far as a code beautifier, within Emacs you can select a region and then do M-x indent-region to autoindent everything you've selected. ---John -- 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: Clarification on setting up Clojure, Lein and Emacs on fedora
On Saturday, December 29, 2012 10:52:15 PM UTC-5, John Gabriele wrote: Sayth, Not sure I follow everything in your post, but here are some tips: 1. You don't need to install Clojure itself. Leiningen takes care of that for you. See Whoops, sorry, forgot to finish typing that :) : I meant to add, See https://github.com/clojuredocs/cds/blob/master/articles/tutorials/getting_started.md . ---John -- 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: Clarification on setting up Clojure, Lein and Emacs on fedora
I believe Fedora ships with Leiningen 1.7.1, which is not what you want. It's better to install manually, see http://leiningen.org; that way you will get 2.x. Don't install Clojure or Contrib through your OS package manager. The Emacs support for Clojure is documented here: https://github.com/technomancy/clojure-mode/blob/master/doc/index.md Please let us know if there's anything unclear that could be improved about that documentation; it's always helpful to get a fresh perspective when it comes to docs. -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: Emacs launching 2 java processes
On Sat, Dec 29, 2012 at 7:12 PM, Alice dofflt...@gmail.com wrote: I'm using emacs with inferior-lisp setup to use lein repl. Everything works fine, but when I start the repl, I see two java.exe processes on my windows task manager. Is this normal behavior? Why two java processes not one are needed? This is normal. Two processes are needed because one is running Leiningen and one is running your project. They need to be isolated so Leiningen's own dependencies don't interfere with your project. However, it's possible to allow Leiningen's JVM to exit before launching your project; try `lein trampoline repl` for that. (I'm not sure how well this works on Windows though.) -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: Clarification on setting up Clojure, Lein and Emacs on fedora
On Sunday, 30 December 2012 15:31:42 UTC+11, Phil Hagelberg wrote: I believe Fedora ships with Leiningen 1.7.1, which is not what you want. It's better to install manually, see http://leiningen.org; that way you will get 2.x. Don't install Clojure or Contrib through your OS package manager. The Emacs support for Clojure is documented here: https://github.com/technomancy/clojure-mode/blob/master/doc/index.md Please let us know if there's anything unclear that could be improved about that documentation; it's always helpful to get a fresh perspective when it comes to docs. -Phil Thank you Phil. I have just reported that leinigen 1.7 is un-installable on F18 due to a mass of broken dependencies. Don't install Clojure or Contrib through your OS package manager. Oops ok, yum remove them then as I had already installed them. https://github.com/technomancy/clojure-mode/blob/master/doc/index.md will read and let you know if I find anything that could be improved. Sayth -- 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: Will the JVM will always likely, remain the primary Clojure implementation ?
If longevity is your top most concern, I have a suggestion here: http://www.itarchitectforumblog.com/content/application_development/cobol_dead_language_rising.html And if you do not think it's all around us: http://itsacobolworld.blogspot.ca/?m=1 This thing has been alive and kicking since the 60s and has it seems a bright future. However, do not expect to do anything significant under 15000 locs per code units (aka namespace) or to become functional any time soon :))) Life is made of compromises... Luc P. If you don't get a flood of responses, I think it is because in this thread and the one linked earlier that Leon Adler started, several different people have explained evidence that Clojure on the JVM has had active development for five years, it is open source, and no one knows of any evidence that this will change any time in the future. That isn't the same as saying will remain, but it is the best anyone can give you that is based on evidence and reason, rather than some other dubious methods. If you believe another language will give you better assurances than that about its future target/platform, I don't see how you came to that conclusion, unless it is by making up conclusions out of thin air. Andy On Dec 29, 2012, at 2:58 AM, Leon Adler wrote: That's unforeseeable because, that represents a very long time. Having said that, this statement deserves a resay... The JVM will remain the primary target/platform for Clojure, while Oracle remains good i.e. it doesn't get Barmy. What say the other people? On Saturday, December 29, 2012 3:53:12 PM UTC+5:30, Sukh Singh wrote: Having read the posts all over again, can I say that the JVM will remain the primary target/platform for Clojure, while Oracle remains good i.e. it doesn't get Barmy ? Isn't that unforeseeable? On Thursday, December 27, 2012 4:56:52 PM UTC+5:30, Sukh Singh wrote: Hi, I have noticed that this question is randomly appearing in many minds, and it is frequently being asked, though there is no apparent reason on why it is asked :/ or maybe people are unable to pen down the exact reasons, and sad to say, even myself. There are reasons for which I ask this question - People (Majority) tend to stick with the primary implementations of certain multi-implementation software. And in the case of Clojure, the JVM implementation is the primary implementation now. Having a primary implementation in case of BDFL lead software helps as a glue in the community. For example , CPython is the primary python implementation, even if there is an existance of IronPython or JPython. The doubts of many, including me, will be cleared by an abstract answer... That 'many' also include the companies adopting something new, in this particular case, adopting clojure QUESTION Rich Hickey chose JVM as the platform of choice when he invented Clojure. It's community developed set of tools and documentation grew around the JVM (Leiningen, for example). From the above statements, can I say that the JVM will always likely, remain the primary Clojure implementation ? Thank 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 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 -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- 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: Unseemingly Eager Clojure Apprentice Seeking FizzBuzz Feeback
2012/12/30 John Gabriele jmg3...@gmail.com: On Saturday, December 29, 2012 5:15:49 PM UTC-5, Sean Chalmers wrote: ... but changing it to more pure function would probably deal with that. Another benefit of pure functions is that they're easier to test. I'll have a play with 'when' as well, hadn't tried that one yet. `when` provides an implicit `do`, so I generally try to only use it when I want side-effects. (Other side-effecty forms include `do`, `doseq`, `dotimes` and `when-not`.) On the other end, using when allows you to be explicit in your code that there's no else clause ---John -- 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
Strange behavior with future
Hi! I'm trying to play a sound in my application, using http://www.javazoom.net/javalayer/documents.html that lib. Anyway, I tried playing the sound in a future, so the main thread would not block while playing, like so: (future (- in Player. .play)). But if I don't deref the future, the sound does not play. If I do deref it, the sound plays, but I have to wait for it, which is what I wanted to avoid. If I do (future (do (println called) (- in Player. .play))), without a deref, it prints called but does still not play the sound. If I do (future (do (- in Player. .play) (println called))), without a deref, it neither prints nor plays. What could be wrong? I'm using clojure 1.4.0 and `lein trampoline run -m ns/main` to run my program. -- 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
