Re: Libraries and build management hell
On Sat, Jul 30, 2011 at 5:27 PM, Mark Engelberg mark.engelb...@gmail.com wrote: I guess what I'm thinking of is that 95% of the time when I go to start something new, it ends up being for a short-lived task Sounds like both Phil and I tackle that by having one or more scratch projects that we just add new dependencies to as needed. Anything that becomes longer-lived is promoted into its own project if/when it makes sense. I'm not sure how well that would work with the way I have things organized, and with my source control, but it's something I can look into. I guess our definitions of one-off might be different? If I'm just doing a one-off experiment in the REPL, it's not likely to end up under version control. If it's long-lived enough to go under version control, it's probably worth a project :) I definitely agree that compared to certain scripting languages, there's more ceremony with Clojure (or any other JVM language) because you can't just drop a source file in any old folder and run it. If you don't mind a compilation step, ClojureScript - JavaScript and then running it with Node.js allows you to have scripts anywhere and easily run them... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Libraries and build management hell
Mark Engelberg mark.engelb...@gmail.com writes: Phil makes a reasonable point that it is possible to create a single project for one-off tasks. I'm not sure how well that would work with the way I have things organized, and with my source control, but it's something I can look into. I have a scratch project which I use for that sort of thing. I still use M-x slime (not lein swank or that new jack-in stuff) when doing non-project stuff. I don't know if M-x slime is still supported in newer versions, I haven't updated swank-clojure in ages. I hope it is, it's really handy. M-x slime just picks up jars from ~/.swank-clojure so I just turn that into symlink for my scratch project's lib directory. Here are the steps for setting it up (once off): 1. Create a scratch project. $ cd ~/src lein new scratch 2. Edit ~/src/scratch/project.clj with whatever libs you want. The essentials: :dependencies [[org.clojure/clojure 1.2.1] [org.clojure/clojure-contrib 1.2.0] [swank-clojure 1.2.1]] Newer swank-clojure jars don't work with the old elisp (1.1.0) I'm running. Use whatever works for you. 3. Fetch 'em: $ cd ~/src/scratch lein deps 4. For M-x slime in Emacs: $ ln -s ~/src/scratch/lib ~/.swank-clojure 5. Make up a ~/bin/clj launch script for CLI use and chmod a+x it: #!/bin/sh exec rlwrap java -cp $HOME/src/scratch/lib/* clojure.main $@ Now use M-x slime and clj as you would expect. If you want to install some more jars, update the scratch project.clj, rerun lein deps and restart emacs. What's much nicer about this than the Python/Ruby model is that whatever libs you put in your scratch area are not automatically on the load path for all your proper projects. That keeps away the load path pollution and version conflict issues that led to the creation of ugly workarounds like RVM. -- A fun little project for someone might be to wrap this workflow into a tiny lein plugin with a couple of convenience commands for setting it up and updating project.clj. Perhaps something like: leni scratch setup # init project, clj script, swank symlink lein scratch install foo 1.5.0 lein scratch uninstall foo lein scratch swank lein scratch repl -- Tip: If you create a symlink from a source *directory* (not a jar) into ~/src/scratch/lib and just name it .jar swank and lein will both stick that directory on the classpath. They don't actually check that it's a jar file. So if you've got lots of mini-projects scattered around that you want on your scratch classpath you can just do something like: $ ln -s ~/src/coolproject/src/ ~/src/scratch/lib/coolproject-src.jar $ ln -s ~/src/junk-clj-files ~/src/scratch/lib/junk.jar -- 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: Libraries and build management hell
My solution to these problems is my run command, where you can run a script in the dependency context of a particular project. So lets say you have a scratch project with many common dependencies. Then I run anywhere, dj run foo.clj scratch-project. I'd imagine there is something like this for cake or leiningen, or at least it would be easy to write a plugin for. On Jul 31, 2:20 am, Sean Corfield seancorfi...@gmail.com wrote: On Sat, Jul 30, 2011 at 5:27 PM, Mark Engelberg mark.engelb...@gmail.com wrote: I guess what I'm thinking of is that 95% of the time when I go to start something new, it ends up being for a short-lived task Sounds like both Phil and I tackle that by having one or more scratch projects that we just add new dependencies to as needed. Anything that becomes longer-lived is promoted into its own project if/when it makes sense. I'm not sure how well that would work with the way I have things organized, and with my source control, but it's something I can look into. I guess our definitions of one-off might be different? If I'm just doing a one-off experiment in the REPL, it's not likely to end up under version control. If it's long-lived enough to go under version control, it's probably worth a project :) I definitely agree that compared to certain scripting languages, there's more ceremony with Clojure (or any other JVM language) because you can't just drop a source file in any old folder and run it. If you don't mind a compilation step, ClojureScript - JavaScript and then running it with Node.js allows you to have scripts anywhere and easily run them... -- Sean A Corfield -- (904) 302-SEAN An Architect's View --http://corfield.org/ World Singles, LLC. --http://worldsingles.com/ Railo Technologies, Inc. --http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript on Windows
You can also add the setlocal command to the .bat file. It will make all variable set commands local to the process (and sub-procs iirc). Better this way because you're not littering in the user's environment. -Bill On Jul 30, 8:14 pm, Benny Tsai benny.t...@gmail.com wrote: Brenton, thank you for your efforts! I noticed that in the current .bat files, CLASSPATH is directly modified and over-written. Perhaps they should instead use CLJSC_CP like the sh scripts? On Saturday, July 30, 2011 10:10:03 AM UTC-6, Brenton wrote: The problems with paths on Windows have been fixed and ClojureScript now has batch files for cljsc, repl, and repljs. There is also a page in the wiki to help Windows users get started. https://github.com/clojure/clojurescript/wiki/Windows-Setup Support for Windows will come from the community so if you care about this then please do pitch in and help. -- 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
timed termination of iterative algorithm
Hello everybody, I would like to have a long running process to return its current solution after some pre-determined amount of time. It so happens that the iteration is happening at a deeper nested function. I would like to have a way to return from this nested function when its time ... How can I do this. Currently I am considering using the throw catch mechanism to do the job. Is there a better way of doing things like this .. . I basically would like to have a non-local return .. something like the common-lisps return-from .. I found return-fromhttp://thinkrelevance.com/blog/2008/09/16/pcl-clojure-chapter-5.html equivalent in clojure.. I was hoping there is a nicer way to deal with this when the function calls are quiet deeply nested.. Thanks, Sunil. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
novel feedback is always welcome
(I have take the liberty of changing the subject line, which may be less than ideal for some people's reading style.) Responses inline. There is something of an issue here, though: where, exactly, should the line be drawn between thou shalt not question this on the mailing list! and fair game for discussion In principle the line is clear. Everything is fair game. Novel feedback is always welcome. Question small decisions, question big ones. Press hard for quality. The opposite of providing novel feedback is recovering old ground. This takes two (often overlapping) forms: (1) Pushing an agenda when you aren't up to speed enough to be in the conversation. (2) Pushing an agenda when project leadership has said, I understand your feedback and disagree. This is not the direction we plan to pursue. Here are some specific examples: (A) The OP on the fess up thread drifted further and further into category (1) as the thread continued. He did not understand the difference between language and platform, and from there was at a loss to understand our decision-making. The very first reply on-thread covered the issue (http://groups.google.com/group/clojure/msg/448a2fec7636e5ad). If only the thread could have died there... (B) A minority of people have pushed back on the numeric changes in 1.3. This is category (2) feedback. There are real tradeoffs here, and Rich has made decisions that not everyone will agree with. You seem to feel that major, already-made design decisions that would require a fork and massive effort to do differently lie on the shalt not question side. What about more minor choices -- for example, which of the three kinds of primitive math overflow behaviors, throwing, auto-promoting, or wrap-around, should be the default? Ken, you are beating a dead horse on 1.3 numerics. You haven't told me anything I don't know already, and you have said several things that suggest that you haven't put in the time that we have to think through the issues. In particular: (1) You think that the overflow defaulting choice is minor, and I think it is fundamental. (2) You were unaware of the platform issues in Java that drove us to implement our own BigInt. That said, Ken's questions on numerics are not unwelcome. It is not realistic for every comer to the mailing list to have encyclopedic knowledge about what has gone before. So nobody should bite anyone's head off for asking a question that has been answered before (particularly if e.g. it is hiding in a deep, convoluted thread and isn't search friendly). Keep the feedback coming! Preferably in atomic chunks with good subject lines. :-) Cheers, Stu Stuart Halloway Clojure/core http://clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: timed termination of iterative algorithm
On Sun, Jul 31, 2011 at 10:25 AM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hello everybody, I would like to have a long running process to return its current solution after some pre-determined amount of time. It so happens that the iteration is happening at a deeper nested function. I would like to have a way to return from this nested function when its time ... How can I do this. Currently I am considering using the throw catch mechanism to do the job. Is there a better way of doing things like this .. . I basically would like to have a non-local return .. something like the common-lisps return-from .. I found return-from equivalent in clojure.. I was hoping there is a nicer way to deal with this when the function calls are quiet deeply nested.. Probably the least messy way to deal with it is to sprinkle (Thread/sleep 0)s through the innermost loops of the algorithm, one in each, and the outermost loop that refines the in-progress result has a try ... catch for InterruptedException that handles it by returning the current approximation. Then have a separate threat that calls interrupt on the calculational thread on a timer, or if a user clicks a Cancel button on a progress dialog, or whatever. This is more or less what InterruptedException is for; and breaking out of an algorithm in an unusual way is the kind of job for which exceptions are well suited, as well as returning from fairly deep up to a specific handler. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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: novel feedback is always welcome
On Sun, Jul 31, 2011 at 10:27 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: In principle the line is clear. Everything is fair game. Novel feedback is always welcome. Question small decisions, question big ones. Press hard for quality. The opposite of providing novel feedback is recovering old ground. This takes two (often overlapping) forms: (1) Pushing an agenda when you aren't up to speed enough to be in the conversation. (2) Pushing an agenda when project leadership has said, I understand your feedback and disagree. This is not the direction we plan to pursue. I'd say there's also (3) Covering old ground you didn't know had been discussed before. Though you might lump that into 1; but there's a difference between not up to speed and should know it and not up to speed with no way of knowing it. (3) is most likely coming from a newbie. Another source of (3) would be if the previous discussions all took place elsewhere, such as IRC or the dev list, that the user hasn't been monitoring. You seem to feel that major, already-made design decisions that would require a fork and massive effort to do differently lie on the shalt not question side. What about more minor choices -- for example, which of the three kinds of primitive math overflow behaviors, throwing, auto-promoting, or wrap-around, should be the default? Ken, you are beating a dead horse on 1.3 numerics. No, I was just bringing it up as an example to illustrate something else. But now that you bring it up ... In particular: (1) You think that the overflow defaulting choice is minor, and I think it is fundamental. Actually, what I think is that the default (once you have a BigInt that is about as fast as a boxed Long when the numbers are small) should be to use BigInt except when primitives are specified, and to use checked primitive math then, with unchecked as an option. This would be most compatible with 1.2's numerics behavior, and still provide all 3 options for arithmetic handling. (I also have concerns about the *unchecked-math* flag I heard about somewhere. We can't have +, etc. testing some flag at runtime -- much less fetching a dynamic Var, which is a slow, slow ThreadLocal object at the JVM level -- before each add without losing performance badly. We really need an (unchecked-math (the-math-goes-here)) macro, or something, that affects what functions get used at *compile time* rather than a dynamic Var flag that is set before performing what you hope to be really fast math.) (2) You were unaware of the platform issues in Java that drove us to implement our own BigInt. That arose in connection with a problem with format, not a gripe with arithmetic. That said, Ken's questions on numerics are not unwelcome. It is not realistic for every comer to the mailing list to have encyclopedic knowledge about what has gone before. That would be my category (3) above. :) So nobody should bite anyone's head off for asking a question that has been answered before (particularly if e.g. it is hiding in a deep, convoluted thread and isn't search friendly). Which, unfortunately, is exactly what happened to me with the numerics thing a while back. :P -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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: novel feedback is always welcome
On Sun, Jul 31, 2011 at 10:41 AM, Ken Wesson kwess...@gmail.com wrote: (I also have concerns about the *unchecked-math* flag I heard about somewhere. We can't have +, etc. testing some flag at runtime -- much less fetching a dynamic Var, which is a slow, slow ThreadLocal object at the JVM level -- before each add without losing performance badly. We really need an (unchecked-math (the-math-goes-here)) macro, or something, that affects what functions get used at *compile time* rather than a dynamic Var flag that is set before performing what you hope to be really fast math.) *unchecked-match* is a compiler flag. David -- 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: timed termination of iterative algorithm
Hi Ken, thank you for your response. Do you think you can give me a quick example of how to extend an Exception to be able to extract the value from the exception when it is caught.. Should I be using gen-class for this? (seems quiet messy to me)... do you have a better suggestion.. Thanks, Sunil. On Sun, Jul 31, 2011 at 7:59 PM, Ken Wesson kwess...@gmail.com wrote: On Sun, Jul 31, 2011 at 10:25 AM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hello everybody, I would like to have a long running process to return its current solution after some pre-determined amount of time. It so happens that the iteration is happening at a deeper nested function. I would like to have a way to return from this nested function when its time ... How can I do this. Currently I am considering using the throw catch mechanism to do the job. Is there a better way of doing things like this .. . I basically would like to have a non-local return .. something like the common-lisps return-from .. I found return-from equivalent in clojure.. I was hoping there is a nicer way to deal with this when the function calls are quiet deeply nested.. Probably the least messy way to deal with it is to sprinkle (Thread/sleep 0)s through the innermost loops of the algorithm, one in each, and the outermost loop that refines the in-progress result has a try ... catch for InterruptedException that handles it by returning the current approximation. Then have a separate threat that calls interrupt on the calculational thread on a timer, or if a user clicks a Cancel button on a progress dialog, or whatever. This is more or less what InterruptedException is for; and breaking out of an algorithm in an unusual way is the kind of job for which exceptions are well suited, as well as returning from fairly deep up to a specific handler. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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: timed termination of iterative algorithm
On Sun, Jul 31, 2011 at 12:41 PM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hi Ken, thank you for your response. Do you think you can give me a quick example of how to extend an Exception to be able to extract the value from the exception when it is caught.. Should I be using gen-class for this? (seems quiet messy to me)... do you have a better suggestion.. Oh, I wasn't suggesting putting the data in the exception. From the sounds of it you have something like (defn outer-loop [...] (loop [x initial-value ...] (recur (compute-new-x x ...) ...))) (defn compute-new-x [x ...] (... (further-computational-steps y ...) ...)) (defn further-computational-steps ...) ... (defn deeply-nested-loop [q z foo] (loop [...] ...)) What I was suggesting was putting some quick thing in deeply-nested-loop that will yield a timeslice and throw InterruptedException if the thread's been interrupted, and in outer-loop catch InterruptedException and handle it by returning the current value of x: (defn outer-loop [...] (loop [x initial-value ...] (let [[new-x ... interrupted?] (try [(compute-new-x x ...) ... false] (catch InterruptedException _ [nil nil nil ... true])] (if interrupted? x (recur new-x ...) -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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: timed termination of iterative algorithm
Another, perhaps cleaner method leverages more of Java's and Clojure's concurrency tools. (def res (atom nil)) (defn outer-loop [...] (loop [x initial-value ...] (reset! res x) (recur (compute-new-x x ...) ...))) ... (defn do-it [timeout ...] (let [f (future (outer-loop ...))] (try (.get ^java.util.concurrent.Future f timeout java.util.concurrent.TimeUnit/MILLISECONDS) (catch Exception _ (future-cancel f) @res The do-it function returns in at most timeout milliseconds. It returns the most recently generated value of res. If the timeout is reached, the get method of Future throws an exception, which gets caught, and the future-cancel method is called on f to interrupt the actual computation. That will still need to be interruptible though or it will run to completion anyway, using CPU to generate a maximally refined result nobody will ever see. Or worse it may run forever. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure Dev: How you can help! (Hint: Alioth Benchmarks)
1) When I saw this posting on Clojure Dev a month ago http://groups.google.com/group/clojure-dev/browse_thread/thread/2abe6d79087af4fc/9030a0b0c15f26a2?hl=enie=UTF-8q=alioth+shootout+clojurepli=1 I recognised the desire to have some quick and dirty performance regression testing, the Scala developers have been using benchmarks game programs for exactly that purpose - http://www.scala-lang.org/node/360 What puzzled me then, and still puzzles me, is why all the work done by Andy Fingerhut and others is being ignored? 2) Also I don't see why this approach - Our approach was to start with the Java solution and do a direct port. Then, examine where we might have bottle-necks and improve. Repeat until we are on par with Java performance. - would create programs that show anything that interesting about Clojure? Of course, for some of those tiny benchmarks game tasks a Clojure program really won't be much different from the Java program - but for others my guess is that something different would be done in Clojure than Java. -- 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 Dev: How you can help! (Hint: Alioth Benchmarks)
Hi Isaac, 1) When I saw this posting on Clojure Dev a month ago http://groups.google.com/group/clojure-dev/browse_thread/thread/2abe6d79087af4fc/9030a0b0c15f26a2?hl=enie=UTF-8q=alioth+shootout+clojurepli=1 I recognised the desire to have some quick and dirty performance regression testing, the Scala developers have been using benchmarks game programs for exactly that purpose - http://www.scala-lang.org/node/360 What puzzled me then, and still puzzles me, is why all the work done by Andy Fingerhut and others is being ignored? Andy spent all his time targeting 1.2. I spend all my time working in 1.3, and have no personal interest in writing benchmarks for 1.2 or older. It is in code such as the Alioth benchmarks where 1.3 is most different from 1.2. That said, in many cases Andy's code would be a good place to start. 2) Also I don't see why this approach - Our approach was to start with the Java solution and do a direct port. Then, examine where we might have bottle-necks and improve. Repeat until we are on par with Java performance. - would create programs that show anything that interesting about Clojure? Fair enough! I certainly was not trying to dictate approach. The suggestion was more about providing a way for people to ease into contributing. Stu Stuart Halloway Clojure/core http://clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Google working on JIT compiler for Dalvik
Thought it might be of interest to some on the list. http://developer.android.com/videos/index.html#v=Oq05KqjXTvs -- 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: Google working on JIT compiler for Dalvik
DOH! http://developer.android.com/videos/index.html#v=Ls0tM-c4Vfo On Jul 31, 2:38 pm, Fred Concklin fredconck...@gmail.com wrote: Thought it might be of interest to some on the list. http://developer.android.com/videos/index.html#v=Oq05KqjXTvs -- 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: Alright, fess up, who's unhappy with clojurescript?
On Jul 30, 6:02 pm, daly d...@axiom-developer.org wrote: While it is fine to say get involved in head-punching I think it is important to realize that it is Rich's head being punched. Seems like I was unclear in my statement. I'll try to do it again. At any point of a lifetime of a computer language there are people that do not agree with some of its design choices. What differentiates young languages from mature ones is the way how these people deal with their disagreement. Year ago a person who was unhappy with some Clojure parts would think: No, Clojure is just not for me. Now this person understands actually how awesome Clojure is, but he is still unhappy with some features. What does he do now? Right, he goes to the mailing list and starts a thread with the topic: Alright, fess up, who's unhappy with Clojure having no goto? This person is not evil, neither he wants to insult the language designers - he just sees this nice tool with minor mistakes (from his perspective) in it and he wonders why such clever people as the language designers made this mistakes (from his perspective). For example, why do people curse C++ and blame Stroustrup so much? Because, after all, C++ is an ubiquitous language. Once he (Bjarne Stroustrup) said: There are only two kinds of programming languages: those people always bitch about and those nobody uses. Clojure finally made it into the first group and that is what I am happy with. Now we have to learn how to live with the side-effects of it. I don't think that such messages should be considered like Rich's head being punched. I don't think that Rich should consider them like an offense to him or to his work. But such situations are inevitable and all of us and Rich in particular have to learn how not to take it to heart. Alexander -- 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: timed termination of iterative algorithm
http://github.com/jpalmucci/clj-return-from On Jul 31, 12:41 pm, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hi Ken, thank you for your response. Do you think you can give me a quick example of how to extend an Exception to be able to extract the value from the exception when it is caught.. Should I be using gen-class for this? (seems quiet messy to me)... do you have a better suggestion.. Thanks, Sunil. On Sun, Jul 31, 2011 at 7:59 PM, Ken Wesson kwess...@gmail.com wrote: On Sun, Jul 31, 2011 at 10:25 AM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hello everybody, I would like to have a long running process to return its current solution after some pre-determined amount of time. It so happens that the iteration is happening at a deeper nested function. I would like to have a way to return from this nested function when its time ... How can I do this. Currently I am considering using the throw catch mechanism to do the job. Is there a better way of doing things like this .. . I basically would like to have a non-local return .. something like the common-lisps return-from .. I found return-from equivalent in clojure.. I was hoping there is a nicer way to deal with this when the function calls are quiet deeply nested.. Probably the least messy way to deal with it is to sprinkle (Thread/sleep 0)s through the innermost loops of the algorithm, one in each, and the outermost loop that refines the in-progress result has a try ... catch for InterruptedException that handles it by returning the current approximation. Then have a separate threat that calls interrupt on the calculational thread on a timer, or if a user clicks a Cancel button on a progress dialog, or whatever. This is more or less what InterruptedException is for; and breaking out of an algorithm in an unusual way is the kind of job for which exceptions are well suited, as well as returning from fairly deep up to a specific handler. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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: Libraries and build management hell
On Jul 31, 12:28 pm, Ken Wesson kwess...@gmail.com wrote: Almost being the operative word. One distinct disadvantage is that it makes building your project require a working network connection snip This is not correct. Once the jar has been downloaded after being included in the dependencies, it stays in your local repository and no network connection is required. Cheers -- 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: Libraries and build management hell
On Sun, Jul 31, 2011 at 9:43 PM, yair yair@gmail.com wrote: On Jul 31, 12:28 pm, Ken Wesson kwess...@gmail.com wrote: Almost being the operative word. One distinct disadvantage is that it makes building your project require a working network connection snip This is not correct. Once the jar has been downloaded after being included in the dependencies, it stays in your local repository and no network connection is required. If you add a new dependency, the network connection is needed. And someone posted something recently about it balking if it's unable to check for updated versions of some things. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
clojurescript interop problems
I'm having some trouble attempting to use interop with ClojureScript. I'm trying to translate examples from the Closure book into ClojureScript, and I keep getting stuck on various things. 1) When using goog.testing, it appears that I can't access goog.testing.TestRunner and goog.testing.TestCase unless those specific namespaces are imported as well. For example: (ns example.core (:require [goog.testing :as testing])) (defn ^:export start-test [] testing/TestCase)) If i call start_test() from the browser repl it returns null. If I add [goog.testing.TestCase :as tc] to the requires, without changing start-test, then the code works fine. 2) Trying to launch the TestRunner fails if i do it in a function, but works if I return the runner and call it from the browser. (defn ^:export start-test [] (let [runner (testing/TestRunner.) test (testing/TestCase. foo)] (.add test (tc/Test. test-html-escaping test-html-escaping goog.global)) (.initialize runner test) ((.execute runner This will throw an exception that the TestRunner is not initialized. However, if I change ((.execute runner)) to runner, then call start_test().execute() it runs perfectly. I can only guess that the this object is not getting set correctly for some reason. Note that changing the last line to (. runner (execute)) also works. 3) Is there some way to export a symbol to be global? For example, goog.testing.jsunit will automatically search the global namespace for test functions, but I can't figure out (aside from js*) how to stick something in there. I basically created start-test above to get around this. jack. -- 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: Libraries and build management hell
On Sun, Jul 31, 2011 at 7:49 PM, Ken Wesson kwess...@gmail.com wrote: If you add a new dependency, the network connection is needed. If you add a new dependency and you don't already have the JAR downloaded, you need a network connection one way or another to go get that JAR, yes? It doesn't matter what tool you use, including manual downloading... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Libraries and build management hell
On Sun, Jul 31, 2011 at 11:57 PM, Sean Corfield seancorfi...@gmail.com wrote: On Sun, Jul 31, 2011 at 7:49 PM, Ken Wesson kwess...@gmail.com wrote: If you add a new dependency, the network connection is needed. If you add a new dependency and you don't already have the JAR downloaded, you need a network connection one way or another to go get that JAR, yes? What if you have the JAR on a disk somewhere, for other reasons, but until now it wasn't a dependency of that particular project? -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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: Libraries and build management hell
What if you have the JAR on a disk somewhere, for other reasons, but until now it wasn't a dependency of that particular project? Your assertion that dependency management systems are in any way disadvantaged to manual dependency management in terms of SPOF or requiring a network connection is merely incorrect. See mvn install:install-file http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html On Sunday, July 31, 2011 9:06:49 PM UTC-7, Ken Wesson wrote: On Sun, Jul 31, 2011 at 11:57 PM, Sean Corfield seanco...@gmail.com wrote: On Sun, Jul 31, 2011 at 7:49 PM, Ken Wesson kwes...@gmail.com wrote: If you add a new dependency, the network connection is needed. If you add a new dependency and you don't already have the JAR downloaded, you need a network connection one way or another to go get that JAR, yes? What if you have the JAR on a disk somewhere, for other reasons, but until now it wasn't a dependency of that particular project? -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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: Libraries and build management hell
On Mon, Aug 1, 2011 at 12:49 AM, pmbauer paul.michael.ba...@gmail.com wrote: What if you have the JAR on a disk somewhere, for other reasons, but until now it wasn't a dependency of that particular project? Your assertion that dependency management systems are in any way disadvantaged to manual dependency management in terms of SPOF or requiring a network connection is merely incorrect. I might be able to disprove your scurrilous charge if I knew what the heck you meant by SPOF. See mvn install:install-file http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html Not relevant. We were discussing use of lein deps. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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: cljs-android - ClojureScript on the Android
Hi All, I'd like to announce cljs-android - ClojureScript on the Android. This is accomplished via the scripting layer for Android (SL4A), and gives you full access to the entire Android API from within ClojureScript. GitHub: https://github.com/ohpauleez/cljs-android Currently, the interface is monkey patched, but moving forward it'll be cleaned up and enhanced. Also note, the only example currently in the code base uses Rhino as the engine, but I also tested and confirmed the same concept works in HTML5/JS app on Android. I have full plans to contribute this to ClojureScript's contrib once it's further along and polished up, and if ever a dialect-specific contrib is formed. Regards, Paul // OhPauleez http://www.pauldee.org/blog -- 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
