Re: Benefits to partial functions.
It's been a long time since I looked at this, but as of a few years ago, the biggest noticeable performance detriment of comp or partial was likely to come if you pass enough args to hit a "& args" overload, which requires creating a fresh object array at each call, when the underlying function being called has a non-"& args" arity. On one application I worked on, we preferred defining #(anonymous ...) functions to some uses of higher order functions to avoid excessive garbage-creation in some hot spots. This assumes you don't need primitive type-hint-level optimization. I wouldn't recommend sacrificing any clarity unless you've profiled and found a real issue. definition of partial: https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2614 definition of comp: https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2557 On Sun, Oct 20, 2019, 3:25 PM david hoyt wrote: > Is there a performance benefit (or detriment) to creating partial > functions? Other than the potential reduction of complexity, is there a > difference between using partial & comp and defining new functions? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/146f2a73-9887-4eba-89c6-815eed6841b1%40googlegroups.com > . > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/CAKK7-VLE_TPdjBuf6g8n0hVLaiMeibS63wJ8UqGDKD1qGZ4T2A%40mail.gmail.com.
Re: Expected inconsistency between set and map w/ ArrayList?
On Mon, May 12, 2014 at 12:53 PM, Alex Miller a...@puredanger.com wrote: My recommendation in Java would be the same - using mutable objects as keys in a map (where mutability changes the hashcode) is a bug waiting to happen. Although I used java.util.ArrayList in the sample REPL session showing the surprising behavior, I never said anything about the Java types used in our application being mutable. That gets at my point: the best Java collection values, the only ones that make good hashmap keys, are immutable, but Clojure still gives them this mixed status where they're equiv but not hasheq to IPersistentCollections w/ the same contents. [Having made that point again, I'll now admit that under the cover of java.util.ListV, the lists in messages our app receives are ArrayLists :-), BUT they're never mutated, and we'd have the same issue if they were Guava ImmutableListV, which is a fine value type (so long as V is immutable).] In general, Clojure treats Java collections (and arrays) as values now ... but if you do mutation, then any Clojure guarantees are off (in hashing, in STM, etc). I think that's been generally a happy compromise so far. The question is to what extent that should continue. I'm totally happy to see crazy things happen to anyone who treats a mutable collection as a value and then mutates it. It may even be that this could be supported without much of a hit. Strings, numbers, keywords, symbols, and all Clojure collections should be handled above the suggested change and that covers most common key types. Some research would need to be done on what common non-Clojure classes (hence not IHashEq implementors) fall into the final else case - java.lang.Class is one that comes to mind which is used a lot inside Clojure itself. I like the sound of this. One of your comments on the ticket mentioned JVM inlining issues, which scared me. Is it a safe bet that protocol dispatch would be too slow for hasheq? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Expected inconsistency between set and map w/ ArrayList?
Is this behavioral change in Clojure 1.6.0 expected? Under 1.6.0, a set and
a map seem to treat a java.util.ArrayList differently with respect to its
equivalence to a vector.
https://gist.github.com/duelinmarkers/7c9f84cfc238e5d37a09
user= (- {} (assoc [1 2] vec) (assoc (java.util.ArrayList. [1 2]) alist))
{[1 2] alist}
user= (- #{} (conj [1 2]) (conj (java.util.ArrayList. [1 2])))
*#{[1 2]}*
user= *clojure-version*
{:major 1, :minor 5, :incremental 1, :qualifier nil}
;
user (- {} (assoc [1 2] vec) (assoc (java.util.ArrayList. [1 2]) alist))
{[1 2] alist}
user (- #{} (conj [1 2]) (conj (java.util.ArrayList. [1 2])))
*#{[1 2] [1 2]}*
user *clojure-version*
{:major 1, :minor 6, :incremental 0, :qualifier nil}
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Name for this pattern: side-effect from swap!
I sometimes find that after mutating an atom, I want to create some side-effect that depends on the old and new state as well as the context in which the change was made. Because of the dependence on context, a watch doesn't work (unless there's something I'm not thinking of). So I add things to the new atom state (returned by swap!) purely to tell the calling code what side-effect to have (or give it the data it needs to decide what side-effect to have). That additional state isn't used anywhere other than the fn that called swap!. One gotcha to this approach is that one must be careful not to leave some old side-effect causing state in place to cause another side-effect based on stale data. Is there a name for this pattern? A standard way of implementing it? A better alternative? One alternative I'm aware of is using mutable locals (provided by https://github.com/ztellman/proteus) as a side-channel of communication from swap!. Both approaches strike me as messy, though a let-mutable probably makes it more obvious that something funny is going on, and it doesn't pollute the atom. Thanks. -hume. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: (series of swap! on atom) == single swap!
On Sat, Feb 15, 2014 at 6:04 PM, t x txrev...@gmail.com wrote: (defn what-I-want [] (with-atom some-atom assoc-in ... assoc-in ... update-in ...)) I often do something like this and don't find it too ugly: (swap! my-atom #(- % (assoc-in [:k] v) (update-in [:k2] inc) ,,,)) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ISeq documentation and mutual deftypes.
On Feb 11, 2014 4:41 AM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: Is the only place this is written down is by working reading the implementing classes? I believe so. Other than the new (and quite minimal) Java API for calling Clojure code[1], the details of Clojure's underlying Java classes are considered implementation details and could change from release to release without being considered a breaking change. [1]: https://github.com/clojure/clojure/blob/master/changes.md#21-java-api -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ISeq documentation and mutual deftypes.
On Tue, Feb 11, 2014 at 7:32 AM, Phillip Lord phillip.l...@newcastle.ac.ukwrote: John D. Hume duelin.mark...@gmail.com writes: Other than the new (and quite minimal) Java API for calling Clojure code[1], the details of Clojure's underlying Java classes are considered implementation details and could change from release to release without being considered a breaking change. And the interfaces? I mean, ISeq is defines the sequence abstraction. When I said underlying java classes I meant underlying Java classes and interfaces. Although there are contrib and third party libraries that depend on these implementation details, I think the message to the community at large has always been not to depend on them, and as far as I know, the maintainers have not committed to keeping anything other than the newly documented Java API and the existing Clojure API in Clojure stable. So if I'm not mistaken, in spite of the fact that you can find many examples of people doing it, there is no blessed way to create custom Clojure data structures (unless you count defrecord) and no official documentation to encourage or assist you. Hopefully I am mistaken, or this will change someday soon. :) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: article about namespace still current?
It includes this update, which I'd say brings it up to date. *update (4/18/2012):** As of the 1.4.0 release, there's no longer a good reason to use use. Use require :refer instead. From the Clojure 1.4.0 * *changelog**: require can now take a :refer option. :refer takes a list of symbols to refer from the namespace or :all to bring in all public **vars* *.* On Feb 8, 2014 2:39 PM, Der Engel engels...@gmail.com wrote: Hi, I'm finding namespaces in Clojure a bit confusion, does know someone if the information in this articlehttp://blog.8thlight.com/colin-jones/2010/12/05/clojure-libs-and-namespaces-require-use-import-and-ns.html (from 2010) is still current with today Clojure best practices and all the idioms are still supported today. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Refactoring as an nREPL middleware
I haven't attempted any code manipulation, just analysis and indexing, but I embarked on a similar idea here: https://github.com/duelinmarkers/insfactor and here: http://github.com/duelinmarkers/insfactor.el. (Nothing Vim-related there, the similar part is trying to put as much as possible of the smarts into the same JVM as the project.) It indexes a simple clojure project and provides a find-usages command, the idea being that find-usages is the first useful step toward rename-var and move-var commands. (I say simple because it still barfs on some common stuff, including defprotocol, IIRC.) Focusing on what you're doing in http://github.com/cgag/nrepl-refactor, the mess I came upon and backed away from when I initially played with transforming code in Clojure is that the forms are easy to manipulate but formatting is hard to maintain. There are also several non-whitespace bits of source that the reader will hide away from you (including comments and #_ forms) but that a proper refactoring tool won't clobber. If you haven't already, you might take a look at https://github.com/cgrand/sjacket. I've been hoping that the new https://github.com/clojure/tools.analyzer work will support some of what source manipulation tools are likely to need, but I haven't looked into it. For example, one hassle with jvm.tools.analyzer (at least the now outdated version I've been using) is that the reader doesn't provide line and column metadata in many places where you'd expect to find it. Another is that it can only show you the post-macro-expansion view of the world. On Fri, Feb 7, 2014 at 3:51 PM, Curtis Gagliardi gagliardi.cur...@gmail.com wrote: Hey everyone, I just wanted to get some feedback on whether or not this is a good idea. I've seen clj-refactor.el recommended a decent amount, but as a dyed-in-the-wool take-no-prisoners vim user, I can't use it. I've always thought it was weird that refactoring was so tightly coupled to editors and IDEs, so I thought I'd try writing some refactors as an nrepl middleware, that would ideally be able to be used across editors. I've only re-implemented the threading and some of the cycling refactors from clj-refactor.el, but it's to the point where I'm going to investigate actually integrating with vim or light table. I've never written any plugins for either of these editors so I might discover there are good reasons I haven't seen refactoring done as a client/server type thing. Anyway, the code is here: https://github.com/cgag/nrepl-refactor , if anyone has any has any feedback I'd love to hear it, and if anyone has vimscript or lighttable plugin experience and wants to help, that'd be great as well. Curtis -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: map semantics
On Fri, Feb 7, 2014 at 9:41 PM, Andy C andy.coolw...@gmail.com wrote: I do perceive sets, lists, vector as atoms which are indivisible (well, this is not true but this is popular meaning) from semantics standpoint. Therefore map is just a function which processes them as whole, again from semantics point of view. Implementation and laziness should not matter really and we still should get the same result. Following your intuition, what would you expect from the following? (map + [1 3 5] '(2 4 6)) # = ? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
On Wednesday, February 5, 2014, Sean Corfield wrote: It's one of the things that has me really hooked on LightTable. I have my source and test namespaces both open. I have them both connected to a REPL. I can evaluate any code, in place, in either file. If I grow some code in the source file, I can put (defn some-name [args]) in front of it and M-) slurps it into a function - done! If I grow some code in the test file, I can put (expect result-value) in front of it and M-) slurps it into a test - done! Could you clarify the difference between LightTable's M-) and using C-M-x* in Emacs jacked into an nrepl session with Cider? * `eval-defun` or whatever cider replaces that with for clojure. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
On Wed, Feb 5, 2014 at 1:27 PM, Sean Corfield s...@corfield.org wrote: On Feb 5, 2014, at 5:39 AM, John D. Hume duelin.mark...@gmail.com wrote: Could you clarify the difference between LightTable's M-) and using C-M-x* in Emacs jacked into an nrepl session with Cider? M-) is paredit-forward-slurp-sexp in both LightTable and Emacs. Sorry, I thought you were saying that kb shortcut is what committed the change to the running JVM. I now see your point that LightTable keeps trying to eval each top-level form and show you the result as you edit, whereas in Emacs you would have to issue a command to see the value of a top-level form. It seems like a small distinction, but I can see how it would make work more fluid. The misconception I hope is disappearing is that REPL-driven development in Emacs necessarily involves lots of switching and copy-pasting back and forth between source file buffers and a REPL buffer. The video in Jay's blog post makes it pretty clear you never need to see the REPL prompt to use the REPL to change a running system. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Profiling, VisualVM random-pause
On Tue, Jan 21, 2014 at 1:50 PM, Yves Parès limestr...@gmail.com wrote: 2) All my methods listed in the profiler are suffixed by .invoke. Is it normal or is pathological of something (I haven't aot-compiled anything, I don't know if it may have an impact here), like unnecessary reflection calls? That's normal. Your fns are compiled to implementors of clojure.lang.IFn, where you can see those invoke methods declared. For methods with rest args, they'll subclass clojure.lang.RestFn, and in profilers you'll see RestFn#invoke calling your function's doInvoke method. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: type hinting overloaded methods
On Tue, Dec 10, 2013 at 4:25 AM, Phillip Lord phillip.l...@newcastle.ac.ukwrote: (defn ^IRI iri [name] (cond (instance? String name) (IRI/create ^String name) (instance? java.net.URL name) (IRI/create ^java.net.URL name) (instance? java.io.File name) (IRI/create ^java.io.File name))) which is a lot longer and, well, just not very nice. I could make this neater with a macro -- something like... (with-types [String, URL, File] (IRI/create name)) which would expand into the cond form above. But the instance? checks seem not ideal. Is there a better solution? You could create and extend an IIriCreate protocol to String, URL, and File. I'd like to point out that Java doesn't provide a clean way to handle this either. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: error-on-reflection
Are you aware of `lein check`? We have our some of our CI builds wired to fail if that finds anything. On Dec 9, 2013 4:12 AM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: I know about *warn-on-reflection* but is there anyway that I can get an error-on-reflection instead? I've been type hinting my application (50% done and yes it goes faster now), and it's a bit painful. What I would really want is to have a unit test which fails if reflection is used. So far, my best idea is catching standard-out and parsing it for reflection warnings. Not ideal. Phil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Clojure-CLR] implement interface that has properties
If I recall, properties are just syntactic sugar for awkwardly named methods. Have you tried the compiler-generated get and set method-names? On Dec 9, 2013 9:50 AM, Frank Hale frankh...@gmail.com wrote: I'm trying to implement an interface that has properties but can't quite seem to get it to work and I also have not found any relevant examples via Google (yet). I'm sure I'm doing something completely wrong here but have no idea how to fix it. (System.Reflection.Assembly/LoadWithPartialName System.Web) (defn foo-handler [] (reify System.Web.IHttpHandler (IsReusable [] false) (ProcessRequest [context] ( IsReusable is a property and I don't know how to tell reify that it is not a traditional function. CompilerException clojure.lang.CljCompiler.Ast.ParseException: Must supply at least one argument for 'this' in: IsReusable Okay, I supply 'this' for IsReusable CompilerException clojure.lang.CljCompiler.Ast.ParseException: Can't define method not in interfaces: IsReusable -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: expand a form
You won't find the results as easy to read as what you're asking for, but clojure.tools.analyzer will show you calls that have been inlined by the compiler. On Nov 25, 2013 2:24 PM, Andy Smith the4thamig...@googlemail.com wrote: In your example a full expansion might be : (. clojure.lang.Numbers (add 10 1)) On Monday, 25 November 2013 17:16:42 UTC, Guru Devanla wrote: Hi Andy, Not sure what you need in terms of function calls being expanded. Can you provide an example. Here is an silly example, even though this kind of macro is not needed: (def addone [v] (+ v 1) (defmacro testmacro [init] (list 'addone init)) (macroexpand '(testmacro 10)) expands to (addone 10) Thanks Guru On Mon, Nov 25, 2013 at 6:32 AM, Andy Smith the4th...@googlemail.comwrote: It doesnt seem to expand function calls though right? On Monday, 25 November 2013 12:55:27 UTC, Andy Smith wrote: Hi, I am new to clojure and I was wondering if there is a macro I can use to fully expand all symbols and macros in a form, without performing the final evaluation of the built in functions? Thanks Andy -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: java.jdbc DSLs (java.jdbc.sql / java.jdbc.ddl)
On Nov 22, 2013 4:09 PM, Sean Corfield seancorfi...@gmail.com wrote: Perhaps a solution here is for me to put it in a library, on Clojars, under a different name and let folks migrate to that as an interim solution (i.e., identical API so folks would just update project.clj and update some ns declarations)? That sounds like a good move. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: preferred way to dereference a ref: outside or inside dosync?
generate-key is not thread-safe. Multiple callers might get the same id. It would probably be worthwhile to have your debit fn disallow a negative balance in some way. Maybe also don't allow closing an account unless it has zero balance. (Though the latter might require coordination between the bank and the account ref, hence bank can't be an atom any more.) Do at least consider the case where one thread already has a reference to an account another thread is closing. My latest iteration has brought me to this: https://github.com/jimpil/bankio/blob/master/src/bankio/core.clj If anyone can think of a more evident and safe approach for demonstration purposes, by all means, shout out. After consulting the Clojure Programming book, I decided to use commute for simply depositing in to an account. There are still 2 fns that use dosync but only modify a single identity, namely deposit! withdraw!. I don't see how else this can be done since they are refs. I would appreciate feedback for this (hopefully) last version... many thanks in advance :) Jim On 21/11/13 13:19, John D. Hume wrote: If you want to demonstrate STM with the deposit-withdraw-transfer example, you definitely need a ref for each account. I'd suggest an atom for the account-num-balance-ref map (the bank) and an atom for the account-num-generator, but you say coordination is necessary for opening and closing accounts. What coordination do you have in mind? On Nov 21, 2013 5:27 AM, Jim - FooBar(); jimpil1...@gmail.com wrote: also I forgot to add that having the bank in some reference type allows opening/closing new accounts, an operation that at least to me sounds like it needs coordination... So which way is preferred? map-ref that stores values, map that stores refs or map-ref that stores refs? Jim On 21/11/13 10:58, Jim - FooBar(); wrote: Hi Stefan, thanks for your interest. let me explain further... 1. I did start with a design that involved a map (the bank) full of agents (accounts). Then I switched to a map full of atoms thinking that I don't really need asynchronous operations. I settled to the single ref approach because it seemed like an overkill to have all these refs inside. Your comment however does make sense...Since there is a single identity, perhaps STM is an overkill... 2. can you ellaborate why you think this is debatable? All the ref-managing fns return the in-transaction value of the ref (i.e. 'alter'). My problem was with 'doseq' which returns nil so I followed the general approach of returning the in-transaction value of the ref after it commits. 3. As I understand it these 2 transactions will be composed/merged into a single transaction. Again, originally I had a bare 'alter' (no dosync) on the private fn transfer1 simply because it is hidden and not supposed to be used...think of it as a helper fn for 'transfer'. but then I read somewhere that transaction can be nested without a problem so I thought it is safer to include 'dosync' in tranfer1 as well... I'm not getting you wrong, don't worry...this is the reason I started this thread - need some answers /feedback :) Jim On 21/11/13 10:42, Stefan Kamphausen wrote: Hi, I may be missing something here, since this thread leaves me a bit confused. 1. Why are you using a Ref for the bank in the first place? It is a single identity and thus should be an atom, because you do not need to coordinate changes of at least two identities. If I am not mistaken, the generic bank transfer example is to have a Ref for each of the accounts and to make sure, that there is never a state of the world in which the money is missing or is available twice. 2. Even our side-effecting fns return something (per alter) which is good. - That seems debatable to me. 3. Why do you nest transactions on the same Ref in transfer1 and transfer? Don't get me wrong, what you're doing may be fine. In that case, I just don't get it. Which, in turn, may be a relevant feedback to you, since this is to be educational :-) Kind regards, Stefan -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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
Re: preferred way to dereference a ref: outside or inside dosync?
If you want to demonstrate STM with the deposit-withdraw-transfer example, you definitely need a ref for each account. I'd suggest an atom for the account-num-balance-ref map (the bank) and an atom for the account-num-generator, but you say coordination is necessary for opening and closing accounts. What coordination do you have in mind? On Nov 21, 2013 5:27 AM, Jim - FooBar(); jimpil1...@gmail.com wrote: also I forgot to add that having the bank in some reference type allows opening/closing new accounts, an operation that at least to me sounds like it needs coordination... So which way is preferred? map-ref that stores values, map that stores refs or map-ref that stores refs? Jim On 21/11/13 10:58, Jim - FooBar(); wrote: Hi Stefan, thanks for your interest. let me explain further... 1. I did start with a design that involved a map (the bank) full of agents (accounts). Then I switched to a map full of atoms thinking that I don't really need asynchronous operations. I settled to the single ref approach because it seemed like an overkill to have all these refs inside. Your comment however does make sense...Since there is a single identity, perhaps STM is an overkill... 2. can you ellaborate why you think this is debatable? All the ref-managing fns return the in-transaction value of the ref (i.e. 'alter'). My problem was with 'doseq' which returns nil so I followed the general approach of returning the in-transaction value of the ref after it commits. 3. As I understand it these 2 transactions will be composed/merged into a single transaction. Again, originally I had a bare 'alter' (no dosync) on the private fn transfer1 simply because it is hidden and not supposed to be used...think of it as a helper fn for 'transfer'. but then I read somewhere that transaction can be nested without a problem so I thought it is safer to include 'dosync' in tranfer1 as well... I'm not getting you wrong, don't worry...this is the reason I started this thread - need some answers /feedback :) Jim On 21/11/13 10:42, Stefan Kamphausen wrote: Hi, I may be missing something here, since this thread leaves me a bit confused. 1. Why are you using a Ref for the bank in the first place? It is a single identity and thus should be an atom, because you do not need to coordinate changes of at least two identities. If I am not mistaken, the generic bank transfer example is to have a Ref for each of the accounts and to make sure, that there is never a state of the world in which the money is missing or is available twice. 2. Even our side-effecting fns return something (per alter) which is good. - That seems debatable to me. 3. Why do you nest transactions on the same Ref in transfer1 and transfer? Don't get me wrong, what you're doing may be fine. In that case, I just don't get it. Which, in turn, may be a relevant feedback to you, since this is to be educational :-) Kind regards, Stefan -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: first vals first vals
On Nov 21, 2013 3:32 AM, Zhemin Lin lin.zhe...@gmail.com wrote: What if :cf, :cq are not fixed, and I don't really care about the keys, but only the value of the value of the value ...? Maps seem an awkward choice of data-structure for a scenario where you don't know or care about the keys. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Generating functions from data
After some experience with excessively meta-programmed Ruby apps, I generally try to design an API that is as clean (or almost) as what I'm tempted to generate and avoid the metaprogramming. For example (api/get-user-by-id 123) is only slightly nicer than (api/get-by-id :user 123), so if the former requires code that some of the team will be afraid to touch, or requires an extra build step, I prefer the latter. Maybe if you spell out some of the boiler-plate you want to eliminate we'll have a better idea of what you're trying to achieve. On Mon, Nov 18, 2013 at 8:51 PM, Jeremy Heiler jeremyhei...@gmail.comwrote: On Mon, Nov 18, 2013 at 7:48 PM, Jeremy Heiler jeremyhei...@gmail.comwrote: I am interested in what you think about generating functions at compile time (with a macro) from data. The specific use case I am thinking about pertains to libraries for large web services with a lot of endpoints. A cost-benefit analysis could probably be done for what size is appropriate, but lets just assume the number of endpoints is large enough for you to start thinking about this. Potential advantages include: - Less boilerplate. It would be less annoying to maintain data that represents each endpoint and generate the boilerplate than it is to maintain a lot of repetitive code. - Shareable. The work done to maintain the endpoint data could be used by multiple libraries for multiple languages. In fact, it could be maintained by the web service itself. Potential disadvantages include: - Limited discoverability. If the code is generated at compile time, there is no direct source for it, which may hinder the ability to view or generate documentation with your favorite tool(s). - Complicated edge cases. Endpoints that require extra code are usually edge cases, but not always. Regardless, breaking from the template may complicate the code further. (I don't think this is a difficult problem to solve, though.) One way to alleviate the limited discoverability problem is to generate source code at build time. This is what you would do in langauges like Java, and that has always left me frustrated, so I am not inclined to think it's a good idea. However, feel free to make the case! A language like Clojure makes doing this relatively easy, but is it simple? Another consequence of this that I forgot to mention in the mail above is that there will either need to be way for the library to self-execute the macro or require the user to initialize the library. The latter might not be too bad considering global (immutable) configuration such as authentication credentials and URLs are necessary. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://elhumidor.blogspot.com/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Design question - dependencies and function discovery
Rather than having hidden mutable state for wiring events to handlers, would it be clearer if the main namespace just passed an :event-[handlers] map to the event processor? If that would create a huge, frequently changing data structure, each namespace with handlers could expose an :event-[handlers] map of its own, and the main ns could merge-with concat. That would at least make explicit what's currently implied by the main ns requiring all the handler namespaces. On Mon, Nov 18, 2013 at 4:07 PM, dm3 deadmo...@gmail.com wrote: Hello, Looking for opinions :) I'm currently building an event-driven service which consumes events using handlers. Now, the idea is to define a set of handlers (functions of type Event-Unit) in different parts of the service, which are then invoked when an event comes into the system. The dependencies are in the following order: [ns.event-processor] - [ns.handlers] - [ns.handler-1], [ns.handler-2] Definition of a handler in *ns.handler-1* looks like this: (ns.handlers/defhandler Handler1 (on :EventA [event] (do something)) (on :EventB [event] (do something else))) The *defhandler* macro registers the handler in an atom, which is then queried when the *ns.event-processor* receives an event. You might have already figured out that I run into problems when the event processor is invoked and not all of the handler namespaces have been loaded yet. Currently I resolve this by explicitly requiring all of the namespaces which invoke *defhandler* from the main application namespace which constructs the running system. It seems that I'm looking for some cross-ns var discovery mechanism, something like classpath scanning in Java (which smells like an anti-pattern in Clojure). I was wandering whether I'm missing some cleaner/better approach? Thanks, Vadim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://elhumidor.blogspot.com/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] datasource 0.1 - Small clojure library for access to environment dependent configuration.
One piece of feedback: the name datasource is confusing, given javax.sql.DataSource, as seen, for example, at http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html# setting-up-a-data-source On Thu, Nov 14, 2013 at 10:09 AM, Andrey Antukh n...@niwi.be wrote: https://github.com/niwibe/datasource Feedback always welcomed. Andrey -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
cider status
The last (non-authoritative) word on cider on this mailing list[1] was that it is unstable. Is that really the case? Is it just a matter of many packages that depend on it not being updated? I tried checking the official mailing list[2] and was surprised to find that it's private. I'm trying to understand this because I submitted a recipe to MELPA, and they will no longer accept packages that depend on nrepl.el. Thanks. -hume. [1] https://groups.google.com/forum/#!searchin/clojure/cider/clojure/JfS7ZzePtA4/ZAPHHn1zS5gJ Tim Visher: Also, Cider is _unstable_ at this point. I'm still using nrepl 0.2.0 and it's working fine. I would _not_ recommend upgrading to Cider at this point. [2] https://groups.google.com/forum/#!forum/cider-emacs -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Yesql 0.2.1 - Clojure SQL queries rethought.
For me, the one feature that can justify an internal DSL for generating SQL is the ability to compose queries. I assume that's not on the Yesql roadmap. On Nov 11, 2013 5:10 AM, Kris Jenkins krisajenk...@gmail.com wrote: https://github.com/krisajenkins/yesql Yesql is a simple library for blending SQL Clojure together, cleanly. Here's how it works https://github.com/krisajenkins/yesql#rationale, and how to use it https://github.com/krisajenkins/yesql#example-usage. Feedback welcomed, Kris -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Compulsive over-optimization
What kind of optimal do you compulsively rearrange for? Performance? Readability? Amusing terseness? On Oct 18, 2013 6:20 PM, Kendall Shaw ks...@kendallshaw.com wrote: With clojure in particular, I am having trouble not rearranging my code to be what I think is more optimal in ways that seem probably not practical. I've noticed myself doing that when I'm newish to languages and apis. But, I go bonkers with clojure. Do you have any thoughts about how to avoid that, other than Bob Newhart's advice: http://www.youtube.com/watch?**v=Ow0lr63y4Mwhttp://www.youtube.com/watch?v=Ow0lr63y4Mw Kendall -- -- 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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: finding a call to longCast
If you have some idea where to look in your code, or if there isn't much code, I'd take a look at clojure.tools.analyzer/analyze-ns[1]. The output is a little overwhelming, but it's pretty easy to navigate in clojure.inspector. One issue may be finding the call (e.g. to some clojure.core fn) that calls RT.longCast. I don't know how many paths lead to longCast. [1] https://github.com/clojure/jvm.tools.analyzer/blob/master/src/main/clojure/clojure/tools/analyzer.clj#L940but to be clear, I don't mean that you should read clojure.tools.analyzer code, just use it to look at your code. On Mon, Oct 14, 2013 at 11:54 PM, Brian Craft craft.br...@gmail.com wrote: Profiling shows clojure.lang.RT.longCast is currently 25% of the run time of the code I'm working on. It's being called from a routine that manipulates primitive arrays while building a hex string, with aget, aset, inc, and bitwise operations. Looking through the source for those, I can't see where it's being called. How can I find it? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://elhumidor.blogspot.com/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: use lein compile a Java project
I believe :dependencies and :resource-paths will be used for the classpath
at both build and run time. Does that meet your needs?
On Fri, Oct 11, 2013 at 8:00 AM, Gaofeng Zeng ndtm.i...@gmail.com wrote:
How use lein compile a Java project?
I know the java-source-paths can specify the src path. But I don't know is
there any option can specify the lib path that contains dependencies of
Java source.
(defproject crawler 0.1.0-SNAPSHOT
:description FIXME: write description
:url http://example.com/FIXME;
:license {:name Eclipse Public License
:url http://www.eclipse.org/legal/epl-v10.html}
:dependencies [[org.clojure/clojure 1.5.1]]
:source-paths [src/clj]
:java-source-paths [java/NetSpider/src])
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
http://elhumidor.blogspot.com/
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Grenchman, for running Clojure code quickly
On Wed, Oct 9, 2013 at 2:32 AM, Zack Maril thewitzb...@gmail.com wrote: How does this vary from flatland/drip? -Zack Grenchman connects to a JVM-with-nrepl you previously launched. Repeated invocations from the command line will hit that same JVM, potentially building up state over time, and Grenchman knows nothing of the JVM's lifecycle. Drip is a JVM pre-launcher, so every time you run drip (with the same classpath), you're running in a fresh JVM, with no state hanging around from previous invocations. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
On Oct 8, 2013 5:35 AM, Phillip Lord However… I find that I am writing a lot of statements like this: (cond (hash-map? v) …… (vector? v) …… (list? v) ….. :else …..) zcaudate, in what context(s) do you find yourself writing a lot of expressions like that? I rarely want to allow so much flexibility in arguments. I'm wondering if there are idioms to avoid it. I'm not sure a type checker will help in that instance. A type-checker wouldn't no, but a type system would; pretty much every language with a static type system has a type based dispatch somewhere. It would be nice to be able to do (defun fn ([^vector v] ...) ([^list l] ...) ([else] ...) How is Clojure's protocols feature different from what you're describing? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Teaching Clojure to students (how ?)
On Oct 7, 2013 3:29 AM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: Tend to agree with this also. As nice as leiningen is, Clojure seems to inherit from Java bulky projects. Compare these two hello worlds: (println hello world) to #!/usr/bin/python print( hello world ) Both equivalently simple, up and till the point you actually try to run them. The best I came up with is... java -jar ~/.m2/repository/org/clojure/clojure/1.5.1/clojure-1.5.1.jar hello_world.clj which, of course, depends on me having installed leiningen and used it. I'd suggest that Clojure's Hello, World! should happen initially at the repl, where leiningen definitely simplifies the UX. lein repl # from any cwd (println ...) which launches nicely into demonstrating dynamic development. If your students work with Java, I'd make a point of demonstrating the joy of the Clojure repl + Java interop, useful even when your project is pure 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Who uses HtmlUnit?
WebDriver's HtmlUnitDriver is only one of many supported drivers. Most Selenium-using teams I've been on have driven real browsers using another driver (which among other benefits allows one to generate realistic screen shots). The one team I was on that used HtmlUnit (a couple years ago) blamed it for sporadic test failures and had their own patched version that supposedly fixed concurrency issues (that they'd submitted as a patch but had not been accepted). I wasn't close to that research, so I can't attest to the issues personally. On Sun, Oct 6, 2013 at 8:40 AM, Kelker Ryan theinter...@yandex.com wrote: I've never tried it for unit testing, but it's the de facto Java library for headless browsers and it's the driving force behind products such as Selenium WebDriver = http://seleniumhq.org/ I mostly use it for bot creation/automation and it supports many versions of popular web browsers such as Firefox (3.6, 10, 17), Chrome (+ 16), and IE (6, 7, 8, 9) = http://htmlunit.sourceforge.net/apidocs/com/gargoylesoftware/htmlunit/BrowserVersion.html 06.10.2013, 20:23, Mimmo Cosenza mimmo.cose...@gmail.com: Hi all, did anyone give a try to this java based HTMLUnit headless browser for cljs unit test to be used of phantomjs? http://htmlunit.sourceforge.net/ Thanks Mimmo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://elhumidor.blogspot.com/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Type of let form
This seems intentional, not a case of docs lagging behind. If you look at the source of let you can see that it has :special-form true in its metadata so that it will remain documented as special even though it's just a macro. I assume the thinking is that it's more useful to continue to document let, loop, and maybe others as special forms than to tell you they're macros that expand into uglier calls to special forms, and then go on to document (and support the APIs of) clojure.core/destructure and the less sugary, true special forms (let*, loop*, and maybe others). It's probably safe to assume these are implementation details that won't necessarily hold in other dialects of Clojure and that breaking changes in that layer might be introduced in a future version of Clojure and would not be considered a backwards-incompatible change by the maintainers. On Fri, Oct 4, 2013 at 2:47 PM, Amrut amrut.jo...@gmail.com wrote: Thanks. I went through the checkins and looks like it was changed here.https://github.com/clojure/clojure/commit/3129be6d80d315e3be2f77dadcf7e904fc6015f5 This was 6 years back. Maybe it's time to update the documentation for special forms. On Friday, October 4, 2013 11:41:22 AM UTC-7, Gary Trakhman wrote: The definitive authority on what is a special form and what isn't is Compiler.java: https://github.com/clojure/**clojure/blob/master/src/jvm/** clojure/lang/Compiler.java#L39https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L39 On Fri, Oct 4, 2013 at 2:27 PM, Amrut amrut...@gmail.com wrote: Hello, According to this http://clojure.org/special_forms, let is a special form. but the sourcehttp://clojuredocs.org/clojure_core/clojure.core/let tells me that it's a macro that uses let*. I could not find any info on let* form. Can someone please explain what is happening here? TIA -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://elhumidor.blogspot.com/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Type of let form
It seems like at least a gray area. Notably, clojure.core/destructure is one of only 35 undocumented (via metadata) public vars out of almost 600 in clojure.core. Here's the full list (1.5.1): (- 'clojure.core ns-publics vals (filter (comp nil? :doc meta)) (map #(.sym %)) sort) (*allow-unresolved-vars* *assert* *fn-loader* *math-context* *source-path* *use-context-classloader* *verbose-defrecords* -cache-protocol-fn -reset-methods EMPTY-NODE await1 chunk chunk-append chunk-buffer chunk-cons chunk-first chunk-next chunk-rest chunked-seq? destructure find-protocol-impl find-protocol-method hash-combine method-sig munge primitives-classnames print-ctor print-dup print-method print-simple proxy-call-with-super proxy-name unquote unquote-splicing with-loading-context) On Fri, Oct 4, 2013 at 3:48 PM, Gary Trakhman gary.trakh...@gmail.comwrote: I agree user code probably shouldn't rely on the details of what's a special form and what isn't. However, I see no problem with using destructure in user code, I've done so myself, and I don't think it's necessarily platform-specific. It's more obvious the intent when things are intentionally marked 'private'. Seems like anything else is fair-game, with java bits being a clear delineation of host-specific functionality. On Fri, Oct 4, 2013 at 4:20 PM, John D. Hume duelin.mark...@gmail.comwrote: This seems intentional, not a case of docs lagging behind. If you look at the source of let you can see that it has :special-form true in its metadata so that it will remain documented as special even though it's just a macro. I assume the thinking is that it's more useful to continue to document let, loop, and maybe others as special forms than to tell you they're macros that expand into uglier calls to special forms, and then go on to document (and support the APIs of) clojure.core/destructure and the less sugary, true special forms (let*, loop*, and maybe others). It's probably safe to assume these are implementation details that won't necessarily hold in other dialects of Clojure and that breaking changes in that layer might be introduced in a future version of Clojure and would not be considered a backwards-incompatible change by the maintainers. On Fri, Oct 4, 2013 at 2:47 PM, Amrut amrut.jo...@gmail.com wrote: Thanks. I went through the checkins and looks like it was changed here.https://github.com/clojure/clojure/commit/3129be6d80d315e3be2f77dadcf7e904fc6015f5 This was 6 years back. Maybe it's time to update the documentation for special forms. On Friday, October 4, 2013 11:41:22 AM UTC-7, Gary Trakhman wrote: The definitive authority on what is a special form and what isn't is Compiler.java: https://github.com/clojure/**clojure/blob/master/src/jvm/** clojure/lang/Compiler.java#L39https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L39 On Fri, Oct 4, 2013 at 2:27 PM, Amrut amrut...@gmail.com wrote: Hello, According to this http://clojure.org/special_forms, let is a special form. but the sourcehttp://clojuredocs.org/clojure_core/clojure.core/let tells me that it's a macro that uses let*. I could not find any info on let* form. Can someone please explain what is happening here? TIA -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://elhumidor.blogspot.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
Re: Jsonify a Jdbc4Array in Clojure
I believe it was on the clojure-docs page (linked from the
clojure.java.jdbc readme) where they talk about managing your own
connection.
The more idiomatic way may be to wrap the whole thing in some transaction
fn or macro. Sorry I'm not familiar with the API. A lot of vars are
deprecated, but their doc strings don't say what to do instead.
On Oct 2, 2013 9:05 AM, Christian Jauvin cjau...@gmail.com wrote:
Actually, re-reading the jdbc/query doc
http://clojure.github.io/java.jdbc/#clojure.java.jdbc/query
I can't find any reference to this :connection keyword param.. may I ask
where you got it from?
On Wednesday, October 2, 2013 9:50:13 AM UTC-4, Christian Jauvin wrote:
Ah finally, thanks John, the with-open pattern was indeed the missing
piece: it works!
Just to summarize, here's what works for me:
(extend-type org.postgresql.jdbc4.**Jdbc4Array
json/JSONWriter
(-write [o out]
(json/-write (.getArray o) out)))
; plus any other additional required custom JSON writers
(java.sql.Timestamp, Date, etc)
(with-open [conn (jdbc/get-connection *db*)]
(json/write-str
(jdbc/query {:connection conn}
[select * from table with PG array in it..])))
On Wednesday, October 2, 2013 12:06:44 AM UTC-4, John Hume wrote:
I don't use clojure.java.jdbc, so this may be non-idiomatic or just
wrong, but have you tried something like
(with-open [connection (jdbc/db-connection *db*)]
(json/write-str
(jdbc/query {:connection connection}
[SELECT * FROM...])))
On Tue, Oct 1, 2013 at 8:13 PM, Christian Jauvin cja...@gmail.comwrote:
Hi Philippe,
The Jdbc4Array that's causing me trouble is not the outer one,
returned from jdbc/query: that one seems to be properly handled by
json/write-str.
The problem happens with a Postgres table containing a text[] column:
create table something (
something_id serial primary key,
list_of_something text[]
)
In that case the query returns an (inner) array for each record, and
it gets converted to a Jdbc4Array, which, when passed to the JSON
writer, causes the problem.
Querying a table without a PG array works perfectly fine though.
On Tuesday, October 1, 2013 4:21:33 PM UTC-4, Philippe Guillebert wrote:
Hi,
You probably need to realize your query using (doall (jdbc/query ...))
Also, I was wondering, depending on your needs, you could convert
Jdbc4Array into a native type (vector ?) as a post-processing
function of your query and forget about registering JSON writers.
On Tue, Oct 1, 2013 at 9:00 PM, Christian Jauvin cja...@gmail.comwrote:
Hi Roman,
This approach works for java.sql.Timestamp, which was another type
for which a JSON writer wasn't defined in my case.
For org.postgresql.jdbc4.**Jdbc4**Array however, there's something
missing, because I get:
*org.postgresql.util.PSQLException: This connection has been
closed.*
As the person answering me on Stack Overflow suggested, it seems that
the resultset should be somehow processed before the connection is
closed,
but I really don't know how to do given the construct I'm currently
using:
(json/write-str
(jdbc/query *db*
[SELECT * FROM ..]))
where and how could I intercept the resultset that way? Thanks.
On Tuesday, October 1, 2013 12:49:10 PM UTC-4, r0man wrote:
I think you need to implement the JSONWriter protocol for the
Jdbc4Array class, and possibly for the datatypes that are in the
array. This for example makes the json library aware of
java.util.Date classes.
(extend-type java.util.Date
JSONWriter
(-write [date out]
(-write (str date) out)))
Something like this (not tested):
(extend-type org.postgresql.jdbc4.**Jdbc4Array
JSONWriter
(-write [array out]
(-write (seq (.getArray array)) out)))
Roman
On Tuesday, October 1, 2013 3:57:02 PM UTC+2, Christian Jauvin wrote:
Hi,
I asked this question on Stack Overflow yesterday:
I want to jsonify the results of a query performed against a
Postgres table containing a column of type text[], but the problem
is that clojure.data.json.write-str doesn't seem to know how to
handle PG arrays:
*Exception Don't know how to write JSON of class
org.postgresql.jdbc4.Jdbc4Array clojure.data.json/write-generic*
Do I have to supply a custom handler, or is there a simpler way?
http://stackoverflow.com/**questions/19103870/jsonify-a-**
jdbc4array-in-clojurehttp://stackoverflow.com/questions/19103870/jsonify-a-jdbc4array-in-clojure
I'm asking it here in the hope of getting (maybe) a simpler
solution, or at least one I can implement readily, because the problem
I
have with one of the suggestions I received (extending
org.postgresql.jdbc4.**Jdbc4Array to implement the missing
function) is that I don't know how to make it work with my usage
pattern,
which is simply:
(json/write-str
(jdbc/query *db*
[SELECT * FROM ...]))
How do I get the array before the connection is
Re: Jsonify a Jdbc4Array in Clojure
I don't use clojure.java.jdbc, so this may be non-idiomatic or just wrong,
but have you tried something like
(with-open [connection (jdbc/db-connection *db*)]
(json/write-str
(jdbc/query {:connection connection}
[SELECT * FROM...])))
On Tue, Oct 1, 2013 at 8:13 PM, Christian Jauvin cjau...@gmail.com wrote:
Hi Philippe,
The Jdbc4Array that's causing me trouble is not the outer one, returned
from jdbc/query: that one seems to be properly handled by json/write-str.
The problem happens with a Postgres table containing a text[] column:
create table something (
something_id serial primary key,
list_of_something text[]
)
In that case the query returns an (inner) array for each record, and it
gets converted to a Jdbc4Array, which, when passed to the JSON writer,
causes the problem.
Querying a table without a PG array works perfectly fine though.
On Tuesday, October 1, 2013 4:21:33 PM UTC-4, Philippe Guillebert wrote:
Hi,
You probably need to realize your query using (doall (jdbc/query ...))
Also, I was wondering, depending on your needs, you could convert
Jdbc4Array into a native type (vector ?) as a post-processing function
of your query and forget about registering JSON writers.
On Tue, Oct 1, 2013 at 9:00 PM, Christian Jauvin cja...@gmail.comwrote:
Hi Roman,
This approach works for java.sql.Timestamp, which was another type for
which a JSON writer wasn't defined in my case.
For org.postgresql.jdbc4.**Jdbc4Array however, there's something
missing, because I get:
*org.postgresql.util.PSQLException: This connection has been closed.
*
As the person answering me on Stack Overflow suggested, it seems that
the resultset should be somehow processed before the connection is closed,
but I really don't know how to do given the construct I'm currently using:
(json/write-str
(jdbc/query *db*
[SELECT * FROM ..]))
where and how could I intercept the resultset that way? Thanks.
On Tuesday, October 1, 2013 12:49:10 PM UTC-4, r0man wrote:
I think you need to implement the JSONWriter protocol for the
Jdbc4Array class, and possibly for the datatypes that are in the
array. This for example makes the json library aware of
java.util.Date classes.
(extend-type java.util.Date
JSONWriter
(-write [date out]
(-write (str date) out)))
Something like this (not tested):
(extend-type org.postgresql.jdbc4.**Jdbc4Arra**y
JSONWriter
(-write [array out]
(-write (seq (.getArray array)) out)))
Roman
On Tuesday, October 1, 2013 3:57:02 PM UTC+2, Christian Jauvin wrote:
Hi,
I asked this question on Stack Overflow yesterday:
I want to jsonify the results of a query performed against a Postgres
table containing a column of type text[], but the problem is that
clojure.data.json.write-str doesn't seem to know how to handle PG
arrays:
*Exception Don't know how to write JSON of class org.postgresql.jdbc4.
Jdbc4Array clojure.data.json/write-generic*
Do I have to supply a custom handler, or is there a simpler way?
http://stackoverflow.com/**quest**ions/19103870/jsonify-a-**jdbc4a**
rray-in-clojurehttp://stackoverflow.com/questions/19103870/jsonify-a-jdbc4array-in-clojure
I'm asking it here in the hope of getting (maybe) a simpler solution,
or at least one I can implement readily, because the problem I have with
one of the suggestions I received (extending org.postgresql.jdbc4.**
Jdbc4Arra**y to implement the missing function) is that I don't know
how to make it work with my usage pattern, which is simply:
(json/write-str
(jdbc/query *db*
[SELECT * FROM ...]))
How do I get the array before the connection is closed with such a
construct? Is there another way?
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@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+u...@**googlegroups.com
For more options, visit this group at
http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@**googlegroups.com.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
Philippe
--
--
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
Re: Type hints for clojure.set functions
On Sep 28, 2013 1:47 PM, splondike splond...@gmail.com wrote: Can anyone else think of a reason why we should not add type hints to the functions, or why coercing the arguments to sets is better (or something else I haven't thought of)? IIRC, type hints are only used by the compiler to generate non-reflective interop code. If you don't do interop, they have no effect. (So you won't get an exception if you pass an incompatible type, unless there's a Java method call in there, and I doubt clojure.set does (m)any.) Iff clojure.set could call clojure.core/set on the appropriate args with zero performance penalty when the arg were already a set, then I think I'd want it to do so. I'd guess the thinking behind the current code is if they want to do set operations on their data, let them decide when and how to get that data to be a set. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Handling name collisions with clojure.core
I haven't tried this, so apologies if it couldn't even work, but have you considered providing a fn in your library intended to be used inside the ns macro? The refer-clojure :exclude boilerplate could be replaced with something like this. (ns my-thing (:require core.matrix.ns) (:core.matrix.ns/exclude-clojure-core-math-ops) (:use core.matrix)) It's not too much boilerplate, and probably explicit enough for anyone who was going to :refer :all anyway. (Sorry for butchering your lib's name. Mobile keyboard bad for code.) On Sep 4, 2013 8:22 PM, Mikera mike.r.anderson...@gmail.com wrote: Hi all, While building the API for core.matrix, I've fun into a few cases where the best name is a direct clash with clojure.core. Examples are +, zero?, vector?, == In many of these cases, the core.matrix behaviour is a natural extension of the clojure.core function (i.e. it extends the same functionality to arbitrary N-dimensional arrays). I'm not very happy with any of the options I can see for handling this: A) Use the good names in the clojure.core.matrix namespace. Problem: that gives you a ton of nasty warnings of the type WARNING: + already refers to: #'clojure.core/+ in namespace: test.blank, being replaced by: #'clojure.core.matrix/+. Significant boilerplate must be maintained by the user in their ns declaration to prevent these warnings. I don't like forcing users to maintain boilerplate, and I think that normal idiomatic usage should be warning-free. B) Separate the name-clashing functions into separate namespaces - e.g. clojure.core.matrix.operators. Problem: that's something of an artificial division, and again it forces users to do extra ns-management work to access the functions they want. C) Use different names. Problem: names would be worse, and this would be inconsistent and confusing, especially for functions that do effectively the same thing. D) Encourage users to use aliases. Problem: that's horrendously ugly and inconvenient for numerical code. Users with any sense of elegance in their coding style would quite rightly throw their hands up in disgust. Currently we're doing B), I'd prefer to do A) but can't figure out a way to automatically suppress the warnings. Any better ideas? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Java Metadata Wrapper
On Fri, Aug 30, 2013 at 2:16 PM, JvJ kfjwhee...@gmail.com wrote: Would it be possible (or even useful) to create some kind of generic IMeta structure that can wrap other Java objects and have them act like normal, except for the added metadata (or even other Clojure-esque features)? Are you interested in :tag metadata or something else? Just curious what the use-case is. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: problem with edn
On Aug 22, 2013 6:25 AM, Jim jimpil1...@gmail.com wrote: this is funny! I thought about this approach but I originally considered it to be a clever hack rather than the official way to do this... If you need some data persisted or sent over the wire, then it should probably be considered part of a value, and maybe metadata isn't an appropriate place to store it. It could go into the record, as in Meikel's workaround, or in some wrapper structure, if you need to maintain the behavior that records with distinct metadata can compare =. (Or you could embed the data in the record but `#(dissoc % :data-fka-meta)` only when you want to compare while disregarding that data.) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: problem with edn
On Aug 22, 2013 2:19 PM, Softaddicts lprefonta...@softaddicts.ca wrote: Jim, This is indeed a hack and not a best practice, maybe you're not using the right tool for your problem... - If you want to exchange data (think values), you should not be in need of keeping types and meta data Metadata is part of the Clojure environment and part of the value domain it handles. Why should it not be transmitted along with the value ? If the receiver is not written in Clojure it may be questionable an probably not very useful to transmit it but otherwise ? I don't think anyone suggested the type of a record should not be part of its edn representation. Here we're talking about arbitrary metadata. While it is part of the Clojure environment, the way in which it's part of the value domain it handles is... subtle. An important thing to understand about metadata is that it is not considered to be part of the value of an object. As such, metadata does not impact equality (or hash codes). Two objects that differ only in metadata are equal. http://clojure.org/metadata -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: tools for minimizing forward declaration
On Aug 19, 2013 5:53 AM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: That would be true, if I knew what my code was going to do when I started. But most of my code is used to investigate things that I don't understand; so it evolves slowly over time. I don't know when I start what low-level is going to be. So, I'm left with the task of removing forward declarations at the end. I don't think Stuart was suggesting that you start by writing low-level fns at the top but that, as you extract or introduce low-level things to support the idea you're working on, you put them above where you're working (instead of just putting the forward declarations there). -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: function creation, partial or #()
Though in some cases the performance impact could be significant, my concern is readability. My understanding of the concept of partial function application is that it's about supplying some but not all of the arguments. So when I see `partial` in code, I expect more arguments to be supplied later, which is confusing when that's not the case. (Obviously context can make it easy to see that there will be no more arguments, but often that context is not present.) On Tue, Aug 13, 2013 at 7:47 AM, Jay Fields j...@jayfields.com wrote: Say you have a simple function: (defn do-work [f] (f)) When you want to call do-work you need a function, let's pretend we want to use this function: (defn say-hello [n] (println hello n)) Which of the following solutions do you prefer? (do-work (partial say-hello bob)) (do-work #(say-hello bob)) I'd been using partial (which I font-lock**), but a teammate recently pointed out that partial's documentation explicitly calls out the fact that the number of args to partial should be less than the number of args to f. In practice it's been working 'fine', but I can't help but wonder if I'm sacrificing something I'm not aware of (performance?) ** with a font-lock, using partial *displays* the same number of chars as the reader macro solution, and I find it more readable when everything is in the parenthesis. - http://blog.jayfields.com/2013/05/emacs-lisp-font-lock-for-clojures.html -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://elhumidor.blogspot.com/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Making Music with Clojure: Meta-eX
Great demonstration. I'd love to have the camera video side-by-side w/ screencast video (and large enough to read your code as you play). On Thu, Aug 8, 2013 at 9:16 AM, Sam Aaron samaa...@gmail.com wrote: Hey everyone, I just thought I'd give you a heads up of what I'm currently doing with Clojure and Overtone within the music space. I gave a talk at a music tech conference in London a good few months ago and they just put the video online: https://www.youtube.com/watch?v=zJqH5bNcIN0 It's a pretty good description of the kinds of things we do (as Meta-eX) and a demonstration of the power of Clojure for making and manipulating music live in front of an audience. We also put a different spin on the notion of performance testing of our software ;-) The great thing about this video for me is that I can clearly see the huge improvements we've made since then. Clojure is such a joy to hack with and I feel wonderfully productive with it. Our system is a massively concurrent beast handling and coordinating many different streams of information (nREPL comms, MIDI devices, monomes, OSC messages, etc.) in addition to coordinating the synthesis engine with the GLSL shaders. Such fun stuff! For more info, check us out here: http://meta-ex.com Finally, for anyone in the London/Cambridge area - you might want to come to Wysing Arts Festival to see us play: http://www.wysingartscentre.org/whats_on/annual_music_festival Sam --- http://sam.aaron.name -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://elhumidor.blogspot.com/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: paredit-widget, simple swing-based clojure paredit widget
On Mon, Aug 5, 2013 at 8:37 PM, kovas boguta kovas.bog...@gmail.com wrote: https://github.com/kovasb/paredit-widget The bigger idea is that code editing should be available a la carte. Tying something as fundamental as code editing together with IDE concerns (file project management, artifact generation, debugging, etc) is a mistake with profound consequences. That's an interesting idea. How would you envision interactions like jump to definition or even auto-completion working in an editor decoupled from ICE concerns? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async: throwing an exception into the channel
I think I'd rather see separate functions or macros for consuming from a channel with the maybe throw behavior rather than having the standard consume form(s) come with that feature (or threat, depending on whether you want it). At that point you're back to the earlier advice to wrap core.async to fit your approach. As new as core.async is to the Clojure community, it seems premature to build in an error-handling approach that may turn out not to be appropriate for many users. On Aug 1, 2013 5:19 AM, Alice dofflt...@gmail.com wrote: throw! is an explicit operation, and there's no special channel states involved. It's passing an exception like other data that just automatically throws it when taken. So it won't hurt anybody. You can use it when you need it, you can ignore it if you don't need it. Yet, it makes using async functions look almost identical to the sync functions. On Thursday, August 1, 2013 3:37:51 AM UTC+9, tbc++ wrote: The position of core.async is to not specify how exceptions should be done (instead leaving it up to the user). So if that method works well for you, write some macros and use it! Other methods may be the use of supervisor channels. In this model, go blocks that die would enqueue the exception into a global (or shared) channel and the go block would then be re-started by a monitor process. Both methods (and may more) are supported by core.async...it simply doesn't care how you handle exceptions, but it is up to you to specify how they are handled. Timothy On Wed, Jul 31, 2013 at 11:49 AM, Alice doff...@gmail.com wrote: It would be nice to have a function throw! that puts an exception into the channel and throws it when taken, so that I can write (let [c (chan)] (go (throw! c (Exception.))) (go (try (prn (! c)) (catch Throwable t (prn exception) instead of (let [c (chan)] (go (! c (Exception.))) (go (try (let [res (! c)] (if (instance? Throwable res) (throw res) (prn res))) (catch Throwable t (prn exception) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@**googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@**googlegroups.com. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: clojure keyword spec
It's probably worth distinguishing between the spec as documented on clojure.org (or https://github.com/edn-format/edn if you prefer) and what the reader permits. Symbols are documented to begin with a non-numeric character (with a special note in the EDN spec about the names of namespaced symbols following the same first-character rule. Keywords are in both documents described as following the rules of symbols. The first char restriction for symbols makes sense, since they're Clojure's identifier type, and the reader needs to be able to distinguish between a number like `2M` and a symbol. I haven't thought of a reason it's important to have the same restriction on keywords, but there may well be one. Switching gears, you can do this (at least in Clojure 1.5.1): (keyword foo 1) (symbol foo 1) but since the docs say these are invalid, I wouldn't recommend using it in non-throw-away code. On Wed, Jul 31, 2013 at 2:59 PM, Brent Millare brent.mill...@gmail.comwrote: I've been discovering in my code that namespaced identifiers are a wonderful thing. In particular, I am found of namespaced integers as an id. Keywords usually serve the role as identifiers, but currently, the spec does not allow namespaced integers, which is odd since integers are valid as keywords and you can namespace words. Again in table form: Keyword... name-starts-with | has-namespace | is-valid? letter, no, yes letter, yes, yes number, no, yes number, yes, no -- This is odd Can we change this so we don't get stack traces like so? clojure.lang.LispReader$ReaderException: java.lang.RuntimeException: Invalid token: :asdf/3a LispReader.java:220 clojure.lang.LispReader.read core.clj:3407 clojure.core/read core.clj:3405 clojure.core/read interruptible_eval.clj:52 clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn] main.clj:257 clojure.main/repl[fn] main.clj:257 clojure.main/repl[fn] main.clj:277 clojure.main/repl[fn] main.clj:277 clojure.main/repl RestFn.java:1096 clojure.lang.RestFn.invoke interruptible_eval.clj:56 clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn] AFn.java:159 clojure.lang.AFn.applyToHelper AFn.java:151 clojure.lang.AFn.applyTo core.clj:617 clojure.core/apply core.clj:1788 clojure.core/with-bindings* RestFn.java:425 clojure.lang.RestFn.invoke interruptible_eval.clj:41 clojure.tools.nrepl.middleware.interruptible-eval/evaluate interruptible_eval.clj:171 clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval[fn] core.clj:2330 clojure.core/comp[fn] interruptible_eval.clj:138 clojure.tools.nrepl.middleware.interruptible-eval/run-next[fn] AFn.java:24 clojure.lang.AFn.run ThreadPoolExecutor.java:1145 java.util.concurrent.ThreadPoolExecutor.runWorker ThreadPoolExecutor.java:615 java.util.concurrent.ThreadPoolExecutor$Worker.run Thread.java:724 java.lang.Thread.run Caused by: java.lang.RuntimeException: Invalid token: :asdf/3a Util.java:219 clojure.lang.Util.runtimeException LispReader.java:326 clojure.lang.LispReader.interpretToken LispReader.java:211 clojure.lang.LispReader.read -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://elhumidor.blogspot.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
Re: [ANN] verily, non-magic testing lib
I've never tried it, but I like the idea of test fns returning their results. On Jul 24, 2013 8:30 AM, Steven Degutis sbdegu...@gmail.com wrote: Also, I've been considering having a non-side-effecty way of returning test results. What do people think? It would get rid of the last bit of magic in the lib. ;; current style (side-effecty) (defn test-1 [] (let [foo (get-foo)] (expect empty? foo) (expect awesome? foo))) ;; proposed style (more functional) (defn test-1 [] (let [foo (get-foo)] [(expect empty? foo) (expect awesome? foo)])) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: - macro and accessing context
I believe the intended idiom for as- (and the reason it doesn't take a
binding vector, like other forms that create locals) is
(- {}
(assoc :a a)
(as- ctx
(assoc ctx :b (some-fn ctx
On Jul 2, 2013 1:12 AM, Meikel Brandmeyer (kotarak) m...@kotka.de wrote:
Hi,
since 1.5 there is
as-http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/as-%3E
:
(as- {} ctx
(assoc ctx :a a)
(assoc ctx :b (some-fn ctx)))
Kind regards
Meikel
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: reset! and merge for (transient {})
Note that `merge` is basically just `conj` plus nil-checking, so there's a
good chance `conj!` already does what you need.
On Jul 2, 2013 5:33 AM, Amir Wasim amir.wa...@gmail.com wrote:
Is there reset! and merge a possibility for (transient {})
sometimes we have a doseq and it might be requirement sometime.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Is there a better way to update a map atom?
It's worth knowing that the moment is implemented via a compare-and-set,
and if the value has been changed (by another thread), the fn you passed to
swap! will be called again with the atom's new value.
On Jun 28, 2013 11:57 PM, Greg g...@kinostudios.com wrote:
OK, I've found something that shows how these two work when used in the
implementation of a generator:
https://gist.github.com/daveray/1263503
I think I understand what the problem is now:
(reset! id (inc @id))
There's a time gap in between the dereference of 'id' and its assignment
back to 'id' (after being incremented).
With swap!, no such problem exists, because it's an atomic operation where
there is no such time gap between dereferencing, applying a function, and
setting the new value. That all takes place in on magical atomic moment.
If I've got this wrong, please let me know!
Cheers,
Greg
On Jun 28, 2013, at 11:19 PM, Greg g...@kinostudios.com wrote:
Can anyone explain the relationship between swap! and reset! ?
Why is using swap! in this example safe and using reset! not?
I've tried searching google for comparisons of the two but can't find
anything, and the documentation doesn't help much.
Thanks,
Greg
On Jan 21, 2013, at 6:22 PM, Stephen Compall stephen.comp...@gmail.com
wrote:
On Jan 21, 2013 3:28 PM, Jim - FooBar(); jimpil1...@gmail.com wrote:
...or you can go all the way, skipping reset! completely:
(swap! game-objects (fn [objects] (reduce-kv #(assoc % %2 (update-object
%3)) {} objects) ))
Which also has the benefit of being safe, unlike any reset!-based update.
--
Stephen Compall
If anyone in the MSA is online, you should watch this flythrough.
--
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 unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: representing clojure source code as data?
On Jun 23, 2013 1:43 AM, kovas boguta kovas.bog...@gmail.com wrote: what about the other cases? Random java objects and whatnot. Those should be output in an EDN way, though its unclear what they would mean when read. Would there be any attempt to convey their contents or characteristics? Aren't you only worried about representing the structure of the source code? If so, doesn't Java interop just break down into lists of symbols, the dot special form, and maybe a special thing for .methodOrField syntax? Or do you have something other than interop in mind when you talk about random Java objects? It doesn't sound to me like you're interested in representing runtime values. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Function returns nil
If you use for, which is lazy, wrap it in a doall to force it to do its work before with-open closes your reader. On Jun 21, 2013 6:52 AM, Jim jimpil1...@gmail.com wrote: Only use 'doseq' when you don't care about the reuturn value. In other words only for side-effect-y code. Use 'for' instead... Jim On 21/06/13 11:17, Jay C wrote: Hi, I'm fairly new to Clojure and need help with a problem. The following function always returns nil, whereas it should return the value of line (which is not nil - I've tested). (defn find-line-in-output [regex] (with-open [rdr (reader belarc-output-filepath)] (doseq [line (line-seq rdr)] (if (not (nil? (re-find (re-pattern regex) line))) line ) ) ) ) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why does peek on a seq of vector fail?
On Jun 20, 2013 3:11 PM, Jason Gilman jason.gil...@gmail.com wrote: (defn bar [my-list n] (if (= n 0) (peek my-list) (bar (rest my-list) (dec n (bar [1 2 3] 1) It seems likely you want either first and rest* (to work from the front of any seqable) or peek and pop (to work from the back of a vector or the front of a list or queue). Combining peek and rest on a vector as the bar function does makes no sense, since they work at opposite ends. *or next in place of rest. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Performance optimizations dealing with java collections
Offhand it looks like the only RestFn you call from filter-link is
clojure.core/format. Have you tried replacing that with something like this?
(String/format (.get link 1) (doto (make-array String 1) (aset 0 (.get link
2)))
I'm not suggesting that's idiomatic, but if it addresses the issue then you
can focus on the difference and look for a happy medium.
On Tue, Jun 18, 2013 at 4:10 PM, Tim Jones timothy.jo...@hp.com wrote:
(defn- filter-link
Format lang and cc into the link returned from the product.
[^List link]
[(.get link 0) (.get link 1) (.get link 2) (.get link 3)
(- (.get link 4)
(URLDecoder/decode UTF-8)
(format (.get link 1) (.get link 2)))])
(defn link-info
Retrieve all link info from a product as a lazy-seq of vectors of
String. The function
handles parameter substitution within the URL
[^Product p]
(map filter-link
(.getAllLinkInfo p @lib {h_lang %1$s h_cc %2$s})))
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: with-open and for
On Jun 11, 2013 8:25 AM, Meikel Brandmeyer (kotarak) m...@kotka.de wrote:
Or another one:
(defn filter-lines
[rdr]
(- (line-seq rdr)
(mapcat #(str/split % #\s+))
(filter #(= 4 (count %) 9))
(into #{})))
(defn filter-file
[filename]
(with-open [rdr (io/reader filename)]
(filter-lines rdr)))
I like this split a lot, though I'd prefer to pass the line-seq to
filter-lines. Then you have an extremely simple impure fn and all your
logic in an easy-to-test, easy-to-reuse pure function.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: clojure diffs
One neat hidden Github feature is that if you add the query string parameter w=1 to any diff view, it will ignore whitespace-only changes (like passing -w to git diff). That doesn't help with those final lines with added or removed close parens, but it still improves readability of many diffs. https://github.com/blog/967-github-secrets On Jun 6, 2013 9:31 PM, Moocar anthony.mar...@gmail.com wrote: Hi all, Diffs for clojure code (and lisps in general) can be hard to read. Every time we wrap a form, any lines below are indented. The resulting diff just shows that you've deleted lines and added lines, even though you've only changed a few characters. What diff tools do people use to address this? I've found ediff is useful in emacs, but what I really want is a way to see good diffs in github pull requests. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: A blocking lazy sequence populated by multiple worker threads
On May 30, 2013 4:12 AM, Colin Yates colin.ya...@gmail.com wrote: ; the following would need to reify itself to be a Runnable, not got that far yet :) (defn execute [job result-queue] (let [result (job)] (.put result-queue result))) A no-args fn is both a perfectly good Callable and a perfectly good Runnable, making interop with java.util.concurrent pretty painless. So it takes as little as #(execute my-job my-queue) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Some feedback on coding style
On May 26, 2013 8:53 PM, Mark Engelberg mark.engelb...@gmail.com wrote: Another possible design choice is to store a domain-testing predicate in the function's metadata. Using metadata would be a much more idiomatic choice than using arity. Multiple arities are idiomatically used (like method overloading) to default arguments. An interesting detail James thought of but didn't call out is putting the domain check in the :pre metadata of the fn. This is an infrequently used Clojure feature, but it's a perfect fit for partial functions. Calling a fn with an argument that fails the :pre check will throw an exception, so the body can be written to assume it's got good input. Anyone can grab the :pre metadata to test for applicability, and anyone who knows clojure will have at least passing familiarity with the concept. Your macro can still pull apart the pattern matching forms to build the :pre fn, and it's still easy to do orElse-style composition. Unrelated: If you haven't already, you may want to read and follow up on the May 16 thread core.match before going very far with it. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Some feedback on coding style
Oops. That is what I meant, but I don't know why I thought pre- and
post-conditions get stored in metadata. It would be handy for :pre. Thanks,
Ambrose.
To the OP, I would still recommend using metadata to store the
applicability test and also making it a precondition of the fn in a partial
function implementation, but that will require more effort than I thought.
On May 27, 2013 8:12 AM, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
Hi John,
By :pre, do you mean function preconditions? eg. (fn [] {:pre [..]}) ?
How is :pre related to metadata and dispatch? AFAICT it's purely for
macroexpansion and
there is no metadata available on the precondition post-macroexpansion.
Thanks,
Ambrose
On Mon, May 27, 2013 at 9:00 PM, John D. Hume duelin.mark...@gmail.comwrote:
On May 26, 2013 8:53 PM, Mark Engelberg mark.engelb...@gmail.com
wrote:
Another possible design choice is to store a domain-testing predicate
in the function's metadata.
Using metadata would be a much more idiomatic choice than using arity.
Multiple arities are idiomatically used (like method overloading) to
default arguments.
An interesting detail James thought of but didn't call out is putting the
domain check in the :pre metadata of the fn. This is an infrequently used
Clojure feature, but it's a perfect fit for partial functions. Calling a fn
with an argument that fails the :pre check will throw an exception, so the
body can be written to assume it's got good input. Anyone can grab the :pre
metadata to test for applicability, and anyone who knows clojure will have
at least passing familiarity with the concept.
Your macro can still pull apart the pattern matching forms to build the
:pre fn, and it's still easy to do orElse-style composition.
Unrelated: If you haven't already, you may want to read and follow up on
the May 16 thread core.match before going very far with it.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: How to: reduce boolean operations?
On Fri, May 24, 2013 at 1:25 PM, atkaaz atk...@gmail.com wrote: It kinda makes sense except I wouldn't have expected that on the map it would return a vector (but then how else could it return both key and value right? ) so everyone expects the input to the pred would be a vector when passed in a map. It's actually a clojure.lang.MapEntry, which is a java.util.Map$Entry that's also a clojure.lang.IPersistentCollection that acts like a vector. So if you conj onto it, you get a vector with three things, and likewise other fns that work with colls will give you vector results, but you can also call clojure.core/key and clojure.core/val on it (or hand it to Java code that expects a map entry). -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to: reduce boolean operations?
On Thu, May 23, 2013 at 11:30 AM, atkaaz atk...@gmail.com wrote: So all I was saying above is that it should throw when [] is empty just as it does when [] is not empty, but it doesn't throw when empty because it's never called (by it i mean false not false?) This sort of behavior is handy for users new to the language but generally goes against the grain in a dynamic language (e.g., Clojure, Ruby, Python, JavaScript). If you want libraries to consistently error when you try to pass the wrong sort of thing to a method or function, there are a whole bunch of languages that make it inconvenient not to do that (e.g., Haskell, Scala, Java, Go). In a dynamic language this requires extra code in every method or function that makes assumptions about its arguments' types. People who choose dynamic languages often do so in part because of how little code it takes to do powerful things. So I think the communities largely see validation of arguments as clutter. That doesn't mean it's never done, but it's kept to a minimum. For example, clojure supports adding :pre and :post conditions to a fn's metadata, but that feature seems to be used only three times in clojure itself: twice in clojure.reflect.java and once in clojure.uuid. On the other hand, many macros in clojure.core validate their usage with the private assert-args. This philosophical bent also comes up in question about how to design a library so that users can't mess up certain things. In the Java community, that's a common concern. In Clojure-land, the prevailing wisdom is to design and document so that it's easy to do the right thing but not worry much about people who do the wrong thing. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to: reduce boolean operations?
On May 22, 2013 5:35 AM, atkaaz atk...@gmail.com wrote: I find the wording of this confusing otherwise it returns the value of the last expr. (and) returns true. I mean, I know it returns the last true value, but that's because I've tested it not because the doc is trying(failing) to tell me so with that phrase. The next-to-last sentence describes the behavior you're talking about. The last sentence is addressing the no-args case. Starting a sentence with a parenthesized form makes it hard to read. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: xslt extension functions in clojure
In the xalan.ext :gen-class the static methods are named foo and bar
but your xslt template is using the (prefixed) names of the clojure impl
fns. Did you try just foo and bar instead?
To be sure the class and methods are available in your test, rather than
calling the clojure fns, call the static methods, like (xalan.ext/foo...).
Hope this helps.
On May 15, 2013 7:08 AM, Gregg Reynolds d...@mobileink.com wrote:
Hi,
I'm having trouble getting clojure functions to work as xslt extensions.
The code is very simple; you can find it at
https://github.com/greynolds/xslj. The problem is obviously related to
how clojure functions get called from java. I have some idea of how that
works but can't figure out how to make it work here. I could always write
a java wrapper to call the clojure stuff but it would clearly be preferable
to not have to do that.
Rather than describe the problem in detail here, the above-mentioned code
is simple and commented so you can see immediately what's happening. It
contains code for both saxon and xalan. (If you're not familiar with xslt,
the idea is just that you can reference an extension function using a URI
in a stylesheet.) If anybody who knows the secrets of calling clojure code
would care to take a few minutes to look I'd be grateful.
The errors I get involve finding the class. But calling the functions
from clojure works just fine. It's not a classpath problem because the
same thing happens using command line processing with explicit classpath
(see the test.sh files in the repo).
Saxon:
XPath syntax error at char 12 on line 15 in {xj:saxfoo(7)}:
Cannot find a matching 1-argument function named
{java:saxon.ext}saxfoo()
Xalan:
java.lang.NoSuchMethodException: For extension function, could not find
method xalan.ext.xalfoo([ExpressionContext,] #NUMBER).
Thanks,
Gregg Reynolds
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Struggling with encapsulation
I agree with the advice you've gotten, but since no one has mentioned it, I
wanted to point out that you can have encapsulation w/o protocols with
something like this.
Assume a queue is your only state and `add` and `clear` are your private
fns that take a queue as first argument.
(defn new-scheduler []
(let [queue (...)]
{:add (partial add queue)
:clear (partial clear queue)}))
There are several disadvantages to this, however. The biggest in my book is
that it achieves your goal, and you're limited in the same way your users
are. You can't add behavior to an already created scheduler (unless it's
built on adding and clearing). Furthermore, if you dynamically recompile
`add` or `clear`, it won't change the behavior of an already created
scheduler, since partial has the fns, not the symbols or vars that point at
them. (These same disadvantages apply to a reified protocol.)
As others have recommended, just return a map. Keep in mind that the
documentation is just a `(doc new-scheduler)` away and that auto-completion
will tend to send people back into your ns's fns rather than into the
internals of a data structure.
On May 10, 2013 5:51 AM, Colin Yates colin.ya...@gmail.com wrote:
Thanks Korny.
Ok, the over-ridding theme seems to be: expose state, even if it is
dangerous, but expect consumers to 'do the right thing' and read the
documentation.
I can see that. I guess I have worked (and to be honest, been guilty
myself) with too many people who don't read the documentation, use
auto-complete to find something that looks like it might work and then move
on to the next chunk of wiring things up in XML :).
I think I also got hung up on the 'data as a contract'. The point here is
that I am not returning data, rather I am defining a service. A subtle
difference but an important one I think.
Keep the comments coming!
On 10 May 2013 11:37, Korny Sietsma ko...@sietsma.com wrote:
I would generally handle this sort of encapsulation at the namespace
level.
Put (create-woobly) and (add-job) and all the other woobly-related
functions into a woobly namespace. Also add any functions that access info
from a woobly bag-o-state, or mutate a woobly to make a woobly-with-extras.
Functions that might dangerously expose internals of a woobly can be made
private, or possibly you can just document them in a way to warn folks away
from bad behaviour.
While external users of (woobly/create-woobly) can in theory dig into the
internals of the woobly object, but it should be relatively obvious that
this isn't a good idea.
I'd defer making protocols until you actually need polymorphism.
- Korny
On 10 May 2013 03:03, Colin Yates colin.ya...@gmail.com wrote:
Thanks for all the helpful responses.
One reason I want to hide the internals is that I don't want people to
add jobs directly to the queue. (add-job) will put a map containing the
provided function onto the queue. Not really relevant, but this is so that
I can track queue timings that I can later on use to determine how much
capacity the system can handle.
I am nervous as well about expose internals but trust people to do the
right thing because in this case, if I was a consumer and saw that queue,
particularly given the emphasis about data being the contract etc. then why
would I think *not* to use it.
I do appreciate the point about not needlessly obfuscating information -
this is a slightly different case.
Sounds like in this case, either reify is the way to go or maybe return
a bad of data but have this stuff in an 'internal' map (i.e. {:internal
{:queue...}})
Thanks a bunch - really helpful.
On 9 May 2013 17:30, James Reeves ja...@booleanknot.com wrote:
On 9 May 2013 17:07, Colin Yates colin.ya...@gmail.com wrote:
The part I am struggling with is how to create a Woobly without
exposing its internals.
To what end? What's the benefit?
If you take a look at some internal data structures Clojure uses, like
zippers or protocols, you'll notice that they're just maps. In general
there's no need to try and obfuscate data to stop people from diving into
the internals; just don't provide a public API for the internal parts and
people will get the hint.
- James
--
--
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 a topic in the
Google Groups Clojure group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/D2OBBPTxGfY/unsubscribe?hl=en
.
To unsubscribe from this group and all its topics, send an email to
Re: Struggling with encapsulation
The add method that you partially apply in new-scheduler should be private,
because a user can't supply the first argument it expects. You might do
something like this.
(defn- add* [queue item] (...))
(defn add [scheduler item]
((scheduler :add) item))
(defn new-scheduler []
(let [queue (...)]
{:add (partial add* queue)}))
But again, I am not recommending this. I just wanted to point out that a
closure gives you encapsulation w/o extra language features.
On May 10, 2013 6:56 AM, Colin Yates colin.ya...@gmail.com wrote:
Thanks John. To be explicit - the add method shouldn't be private - it is
the only way users should add to the queue. I think this is what you meant
but you wrote ..and `add` and `clear` are your private fns...
Again, this paradigm shift of 'trust your users' is unfortunately alien to
me based on my experience with most of the Java devs I have come across :).
I say that not be snarky, but to highlight how much it really does change
things. The open-closed principle now becomes much simpler to realise for
example.
Thanks again.
On 10 May 2013 12:44, John D. Hume duelin.mark...@gmail.com wrote:
I agree with the advice you've gotten, but since no one has mentioned it,
I wanted to point out that you can have encapsulation w/o protocols with
something like this.
Assume a queue is your only state and `add` and `clear` are your private
fns that take a queue as first argument.
(defn new-scheduler []
(let [queue (...)]
{:add (partial add queue)
:clear (partial clear queue)}))
There are several disadvantages to this, however. The biggest in my book
is that it achieves your goal, and you're limited in the same way your
users are. You can't add behavior to an already created scheduler (unless
it's built on adding and clearing). Furthermore, if you dynamically
recompile `add` or `clear`, it won't change the behavior of an already
created scheduler, since partial has the fns, not the symbols or vars that
point at them. (These same disadvantages apply to a reified protocol.)
As others have recommended, just return a map. Keep in mind that the
documentation is just a `(doc new-scheduler)` away and that auto-completion
will tend to send people back into your ns's fns rather than into the
internals of a data structure.
On May 10, 2013 5:51 AM, Colin Yates colin.ya...@gmail.com wrote:
Thanks Korny.
Ok, the over-ridding theme seems to be: expose state, even if it is
dangerous, but expect consumers to 'do the right thing' and read the
documentation.
I can see that. I guess I have worked (and to be honest, been guilty
myself) with too many people who don't read the documentation, use
auto-complete to find something that looks like it might work and then move
on to the next chunk of wiring things up in XML :).
I think I also got hung up on the 'data as a contract'. The point here
is that I am not returning data, rather I am defining a service. A subtle
difference but an important one I think.
Keep the comments coming!
On 10 May 2013 11:37, Korny Sietsma ko...@sietsma.com wrote:
I would generally handle this sort of encapsulation at the namespace
level.
Put (create-woobly) and (add-job) and all the other woobly-related
functions into a woobly namespace. Also add any functions that access info
from a woobly bag-o-state, or mutate a woobly to make a woobly-with-extras.
Functions that might dangerously expose internals of a woobly can be
made private, or possibly you can just document them in a way to warn folks
away from bad behaviour.
While external users of (woobly/create-woobly) can in theory dig into
the internals of the woobly object, but it should be relatively obvious
that this isn't a good idea.
I'd defer making protocols until you actually need polymorphism.
- Korny
On 10 May 2013 03:03, Colin Yates colin.ya...@gmail.com wrote:
Thanks for all the helpful responses.
One reason I want to hide the internals is that I don't want people to
add jobs directly to the queue. (add-job) will put a map containing the
provided function onto the queue. Not really relevant, but this is so
that
I can track queue timings that I can later on use to determine how much
capacity the system can handle.
I am nervous as well about expose internals but trust people to do
the right thing because in this case, if I was a consumer and saw that
queue, particularly given the emphasis about data being the contract etc.
then why would I think *not* to use it.
I do appreciate the point about not needlessly obfuscating information
- this is a slightly different case.
Sounds like in this case, either reify is the way to go or maybe
return a bad of data but have this stuff in an 'internal' map (i.e.
{:internal {:queue...}})
Thanks a bunch - really helpful.
On 9 May 2013 17:30, James Reeves ja...@booleanknot.com wrote:
On 9 May 2013 17:07, Colin Yates colin.ya...@gmail.com wrote:
The part I am
Re: ANN: kits 1.5.1 - some of Runa's core utilities
On Thu, May 9, 2013 at 7:15 PM, Dave Sann daves...@gmail.com wrote: There are several projects that provide a bunch of base level/common functions and extensions (similar to those here) beyond core Clojure. And I am sure that many people have their own collection of useful utilities like this. I know that I do. I wouldn't want to try to wrangle all these together, but I would like to have a list of them for reference. Here are two I know of offhand. https://github.com/jaycfields/jry https://github.com/flatland/useful -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Import java classes in clojure
Did you try the downloads link here? http://openrules.com/jsr331/ On May 6, 2013 12:10 AM, Caocoa p.de.bois...@gmail.com wrote: Well, so I just tried the following commands: user= (ns mx.clojure.contemporary.pitch-centricity-and-symmetry #_= (:import [jm.music.data #_= Score #_= Part #_= Phrase #_= Note]) #_= (:import [jm.music.tools #_= Mod]) #_= (:import [jm JMC]) #_= (:import [jm.util Write])) jm.util.Write mx.clojure.contemporary.pitch-centricity-and-symmetry= It seems to work, right? :) Have I imported jMusic in a clean way? But I've still a problem with javax :-( On Monday, May 6, 2013 12:04:39 AM UTC+2, Caocoa wrote: Hi all! I'm a new Clojure user. I'm trying to import some java classes in order to use them with overtone, but I fail :/ Would you help me? Thanks a lot in advance for your answer. Here is the bug: user= (:import [javax.constraints #_= Problem #_= ProblemFactory #_= Var #_= Solver #_= Objective #_= VarSet]) CompilerException java.lang.RuntimeException: java.lang.**ClassNotFoundException: javax.constraints, compiling:(NO_SOURCE_PATH:1) user= (:import [jm.music.data #_= Score #_= Part #_= Phrase #_= Note]) CompilerException java.lang.RuntimeException: java.lang.**ClassNotFoundException: jm.music.data, compiling:(NO_SOURCE_PATH:1) As a newbie, I have several questions: - I've found jMusic here: http://sourceforge.net/** projects/jmusic/?source=dlphttp://sourceforge.net/projects/jmusic/?source=dlp. I hope it's the latest version. I've copied it in /usr/lib/jvm/java-7-openjdk/**jre/lib/ext but I still can't invoke any jm.music.data classes. How could I include it int the classpath. I thought that folder was already included. - How can I download and properly install javax.constraints? I don't even know where I can find that package. Some data about my system: - uname -a gives me back: Linux C40C04 3.8.11-1-ARCH #1 SMP PREEMPT Wed May 1 20:18:57 CEST 2013 x86_64 GNU/Linux - When I look for jMusic or javax in package database with my package manager (I use yaourt), I don't find anything. - Here is what java packages I've already installed: $ yaourt -Qs java extra/apache-ant 1.9.0-1 A java-based build tool extra/ca-certificates-java 20121112+nmu2-1 Common CA certificates (JKS keystore) extra/eclipse 4.2.2-1 An IDE for Java and other languages extra/gjs 1.36.1-1 Javascript Bindings for GNOME local/hsqldb-java 1:1.8.0.10-2 HSQLDB Java libraries extra/java-activation-gnu 1.1.1-1 JavaBeans Activation Framework (JAF), framework for declaring what beans operate on what MIME type data local/java-commons-email 1.2-1 Library for sending e-mail from Java. extra/java-gnumail 1.1.2-1 GNU implementation of the JavaMail API specification, version 1.3 extra/jdk7-openjdk 7.u21_2.3.9-1 Free Java environment based on OpenJDK 7.0 with IcedTea7 replacing binary plugs - SDK extra/jre7-openjdk 7.u21_2.3.9-1 Free Java environment based on OpenJDK 7.0 with IcedTea7 replacing binary plugs - Full Java runtime environment - needed for executing Java GUI and Webstart programs extra/jre7-openjdk-headless 7.u21_2.3.9-1 Free Java environment based on OpenJDK 7.0 with IcedTea7 replacing binary plugs - Minimal Java runtime - needed for executing non GUI Java programs community/netbeans 7.3-1 IDE for Java, HTML5, PHP, Groovy, C and C++$ yaourt -Qs java extra/apache-ant 1.9.0-1 A java-based build tool extra/ca-certificates-java 20121112+nmu2-1 Common CA certificates (JKS keystore) extra/eclipse 4.2.2-1 An IDE for Java and other languages extra/gjs 1.36.1-1 Javascript Bindings for GNOME local/hsqldb-java 1:1.8.0.10-2 HSQLDB Java libraries extra/java-activation-gnu 1.1.1-1 JavaBeans Activation Framework (JAF), framework for declaring what beans operate on what MIME type data local/java-commons-email 1.2-1 Library for sending e-mail from Java. extra/java-gnumail 1.1.2-1 GNU implementation of the JavaMail API specification, version 1.3 extra/jdk7-openjdk 7.u21_2.3.9-1 Free Java environment based on OpenJDK 7.0 with IcedTea7 replacing binary plugs - SDK extra/jre7-openjdk 7.u21_2.3.9-1 Free Java environment based on OpenJDK 7.0 with IcedTea7 replacing binary plugs - Full Java runtime environment - needed for executing Java GUI and Webstart programs extra/jre7-openjdk-headless 7.u21_2.3.9-1 Free Java environment based on OpenJDK 7.0 with IcedTea7 replacing binary plugs - Minimal Java runtime - needed for executing non GUI Java programs
Re: Clojure Login form error: java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to clojure.lang.Atom
On May 2, 2013 2:04 AM, David Toomey dbtoo...@gmail.com wrote: Is there anything I could show that could reveal the problem? Yes, you should have shown the stack trace of the exception (or at least the part from the top of the text down to your code). But even without that, you have an error coming out of noir.session that says something is unbound where an atom was expected. That should send you to the source for noir.session. There you'll see everything depends on the dynamic global *noir-session*, which is only ever bound by wrap-noir-session, which you're not calling. That's a compojure middleware fn. Take a look at some compojure tutorial to see where and how they're used. There are likely other similar middleware fn calls noir will expect you to have made. Hopefully having struggled with this one, figuring the others out will be easy. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: higher order functions and metadata
On Thu, May 2, 2013 at 8:33 AM, Phillip Lord phillip.l...@newcastle.ac.ukwrote: Well, I guess I will code up a simple macro; in my current case, I can infer the arglists anyway. Once you do, be sure to weigh the complexity against: (defn my-partial-function [y] (my-function 10 y)) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure Login form error: java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to clojure.lang.Atom
I've never used noir and have barely used 4clojure, but both of them apparently do hidden global things that make it hard to know the context in which your code is running. Your app needs to be wrapped in noir's `wrap-noir-session` middleware in much the same way this blog post shows Ring's `wrap-session` being used: http://rjevans.net/post/2628238502/session-support-in-compojure-ring https://gist.github.com/mirrormatch/768768 I'll leave it at that. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [GSOC 2013] Program analysis suite, based on Rich Hickey's Codeq
As a user of Codeq with Navgeet's proposed additions, I would definitely want to see macro usages along with runtime var references. So you're right that you'd want the result of analyzing the subject code with all macros expanded, but it would also be valuable to see the macros that got expanded along the way. On May 1, 2013 5:53 AM, Navgeet Agrawal navgeet.agra...@gmail.com wrote: Ah seems like I did not think that through. For macros it makes sense to do analysis on their expansions. For example, for analyzing a defn form, codeq should examine the expansion's ast. Since I wanted to build all analysis functionality as plugins, therefore source analysis plugins should have access to a defn's full expanded ast, which would adequately allow them to answer questions like Which functions are called by this function?. This should also be able to deal with false positives, since analysis is run on expanded code. Thanks for the feedback, Navgeet -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: testing for nil may not be enough
On Apr 29, 2013 1:07 PM, Jonathan Fischer Friberg odysso...@gmail.com wrote: If you don't want to set the initial value to nil, set it to ::unbound or similar. Should be very hard to accidentally bind the same value. Please take Jonathan's advice if nil is a valid value for a user to bind; use nil as the initial value if it's not. It is non-idiomatic to leave the var unbound for exactly the reason you're running into: unbound vars are annoying to deal with. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: recur doesn't complain when autoboxing fails?
On Sun, Apr 28, 2013 at 5:46 AM, AtKaaZ atk...@gmail.com wrote: = (defn abc [] 3) #'ants/abc = (loop [a 1] (when (= 1 a) (recur (abc NO_SOURCE_FILE:2 recur arg for primitive local: a is not matching primitive, had: Object, needed: long Auto-boxing loop arg: a nil The compiler isn't telling you it will need to box your recur arg into a long, but that it will be boxing your initial loop arg into an Object. Think of the message as Maybe you intended `a` to be a primitive local, but since you passed `recur` a who-knows-what, it won't be. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: conform to interface for related multi-methods?
On Fri, Apr 26, 2013 at 11:58 AM, Steven Degutis sbdegu...@gmail.comwrote: I found that I want to have multiple multi-methods, but grouped together, much like an interface. There's no syntax for grouping multimethods, but wouldn't it be good enough to put the defmulti forms near one another? Presumably they'll share a dispatch fn (or some underlying part of their dispatch fns) and maybe a hierarchy (as in clojure.core/make-hierarchy), which makes it easier to see that this set of multimethods goes together. If your concern is making it fool-proof for consumers of your API to defmethod for all the right multimethods, you can easily do :default defmethods that provide a clear error message. Somewhat less easily you could create a macro that expanded into the right set of defmethod forms. That seems excessive to me, but I don't know your context. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Arrays and indexes
Both `for` and `doseq` support the same vector form preceding a body. `for` returns a lazy sequence and is often appropriate for a purely functional body. `doseq` is not lazy and returns nil, so it is only appropriate when you want to run the body for side effects. Take a look at http://clojure.github.io/clojure/clojure.core-api.html and play around in the repl to get a clearer idea of how that works. Maybe start with an expression like this: (let [nested [[1 2 3] [4 5 6]]] (for [row nested number row] (str number from row row))) If you change `for` to `doseq`, you may also want to change `str` to `println`. Alan's example uses `map-indexed` to get numeric indices. Note that `cols` holds a row from `rows` and is then passed to the second `map-indexed` call, so his example is like a nested for-loop in a C-like language, except that it is lazy and returns a sequence of results of calling `display` with each item from your nested vector along with its coordinates. For this example to make sense, `display` should return a value that will be used to put something on screen. If `display` just does the screen-putting, and its return value is insignificant, then `doseq` would make sense. Hope this helps. -hume. On Apr 19, 2013 4:27 AM, edw...@kenworthy.info wrote: How does that work: you appear to be iterating over two, unconnected, vectors. And yes that's an example of the second option but doesn't explain if or why that's the best approach- which was the question ;) On Thursday, 18 April 2013 19:48:40 UTC+1, Alan Malloy wrote: (for [[y cols] (map-indexed vector rows) [x cell] (map-indexed vector cols)] (display cell y x)) ? On Thursday, April 18, 2013 3:14:19 AM UTC-7, edw...@kenworthy.infowrote: So, I want a 2 dimensional array. I think the best way to implement this is a vector of vectors. Now I want to display that array drawing each element relative to its position in the array. Is the best way to use doseq and manually maintain the indices? Or is it to use nested for-loops manually iterating of the vector-of-vectors? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: destructuring vectors with :or
You can use a map destructuring form on a vector like so:
(let [{x 0 y 1 :or {x 0 y 0}} [7]] [x y])
returns [7 0]
On Fri, Apr 12, 2013 at 5:00 PM, henry clifford h.a.cliff...@gmail.com wrote:
I'm trying to use the :or destructuring syntax as seen here applied to a map
(def point {:y 7})
(let [{:keys [x y] :or {x 0 y 0}} point]
(println x: x y: y))
x: 0 y: 7
but I can't get this to work with vectors:
(def point [7])
(let [[x y :or [0 0]] point]
(println x: x y: y))
what' I'm expecting is x:7 y:0
but I'm getting Exception Unsupported binding form: :or
Any thoughts on this?
Thanks!
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
http://elhumidor.blogspot.com/
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Some docs on comparators, including mistakes to avoid, Clojure extended doc strings
This seems like a good fit for http://clojure-doc.org/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: nested reduce/reduce-kv idiom
On Apr 4, 2013 6:54 AM, Jim - FooBar(); jimpil1...@gmail.com wrote:
Thanks John,
I came up with this, which uses destructuring quite heavily and might
slow things down...
(reduce (fn [s [t1 t2 w3 v]] (assoc-in s [t1 t2 w3] (/ (count v) all))) {}
(for [[k1 v1] ems [k2 v2] v1 [k3 v3] v2] [k1 k2 k3 v3]))
is this what you meant?
Yes, something like that.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Analog to Scheme's partition in Clojure?
On Thu, Apr 4, 2013 at 8:06 AM, David Powell djpow...@djpowell.net wrote:
You could use the long-form of map destructuring:
(let [{odd true even false} (group-by odd? (range 1 10))]
(println odd)
(println even))
I do this frequently. Do be careful that if your predicate doesn't
return actual booleans, you may want to coerce with (boolean ...).
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: nested reduce/reduce-kv idiom
Destructure the map entry. (for [[k vs] some-map, v vs] v) or whatever. On Wed, Apr 3, 2013 at 1:44 PM, Jim - FooBar(); jimpil1...@gmail.com wrote: Hi all, I 've recently come across this idiom (instead of nested reduces - from Christophe's blog post of course!) (reduce f init (for [x xs, y x, z y] z)) ;;it took me a while to realise how cool this is :) I'm trying to do the same for reduce-kv (for nested maps) but doesn't quite work...has anyone done this already? It comes down to 'seq' returning a [k,v] vector when called on a map so the second nesting level will break because it will find a keyword or something similar. any ideas? Jim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://elhumidor.blogspot.com/ -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Problem with map (only when running on browser)
When you want a side effect and don't care about return values, it's idiomatic to use doseq. (doseq [c calls-log] (log-call c)) On Mar 30, 2013 4:23 AM, Neale Swinnerton ne...@isismanor.com wrote: ;(.log js/console (pr-str calls-log (map log-call calls-log))) map is lazily evaluated, so if you never read it's result nothing happens. You can force evaluation with doall (and variants) so... (doall (map log-call calls-log)) will behave as you expect. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Seeking advice on a safe way to mock/stub fns
On Mar 27, 2013 1:56 AM, Shantanu Kumar kumar.shant...@gmail.com wrote: Sorry, in the last illustration, the (binding [*deps* deps] ...) cannot be useful for Compojure route handlers because dynamic vars are bound at a thread-local level; you will probably have to `alter-var-root` it to some var and have the handlers use that static var instead. In the code I write personally, I use a static var that I `alter-var-root` so I couldn't see the error in dynamic var immediately. If that thread-local binding is done in a middleware, that should work fine for ring, which handles each request synchronously on a thread. (Whereas alter-var-root would be visible across threads and defeat the OP's goal of running tests concurrently.) Do note, however, that the premise of this advice, that with-redefs doesn't play nicely with concurrency, is too broadly stated. • It doesn't play nicely with running tests that mock the same vars across multiple threads. • It doesn't play nicely with running tests in one thread while running your app in another, if your app does things w/o user interaction. (This is a pain for me.) • BUT it does play nicely, more so than binding, with testing code that does work across multiple threads, for example in futures, agents, or hand-rolled threading. So if you're testing concurrent code and can stand to run just one test at a time, it allows you to avoid the verbosity of injecting all your dependencies. -hume. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Best way of doing clojure / clojurescript development
https://github.com/emezeske/lein-cljsbuild/blob/0.3.0/doc/CROSSOVERS.md On Mar 27, 2013 6:40 AM, Steven Obua ste...@obua.de wrote: Hi, I have thought long which language to use for my current project. My main choices were Scala and Clojure, and I decided on Clojure mainly because I need to run substantial amounts of my code to run on both the JVM and in the browser. So now I am approaching the parts of my project that need to run in both environments. Are there any best practices for setting up my environment so that I can compile to both the JVM and to Javascript from the same codebase? I am aware that Clojure and Clojurescript are different languages, but for those pieces of my code that are shared I will make sure that the code looks the same, and I don't want to maintain different codebases for the same code. Thanks for any pointers, Steven -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Accessing a resource inside a jar
It looks like MimetypesFileTypeMap wants a path to a plain file. I can't try this right now, but I think you want the constructor that takes an InputStream. Something like (MimetypesFileTypeMap. (io/input-stream (io/resource thefile))) though if you just passed /thefile to io/input-stream, that might do it. On Mar 25, 2013 9:08 PM, Clinton Dreisbach clin...@dreisbach.us wrote: My apologies for a simple question, but: I have a very small library I wrote that needs to read a file in its resources/ directory. In the project, this works fine. However, when I package the library as a JAR, it can't find the file. I thought I was following the best practice of getting the file like so: (.getFile (io/resource mime.types)) mime.types is definitely in the JAR; it's at the root. You can see the project at https://github.com/cndreisbach/ring.middleware.mime-extensions and the problem in particular at https://github.com/cndreisbach/ring.middleware.mime-extensions/blob/master/src/ring/middleware/mime_extensions.clj#L12 . Am I missing some piece of knowledge about my project.clj? Any help you could give would be very appreciated. Thanks, Clinton Dreisbach -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Macro for bailout-style programming
Your maybe- does almost the same thing as Clojure 1.5's some- but without support for naked fns (like `(some- 1 inc)`). It also evaluates each step but the last twice (once for the `if`, once when inserted after `op`). If you don't want to switch to some-, I'd recommend you use when-let to avoid the double evaluation. On Mar 23, 2013 4:12 AM, Gary Verhaegen gary.verhae...@gmail.com wrote: I've recently had a need for something like that in my own code. The real solution to that problem in the functional programming world is known as the maybe monad. Since I just needed a quick and dirty solution and I have not wrapped my head around monads yet, here's what I did : (defmacro maybe- Sort of like a maybe monad, but without a monad. Takes an initial value and a list of functions with their arguments, and returns the result of applying each function to the result of the preceding one as long as there is no nil value. Returns nil if there ever is a nil in the chain of values. [init fns] (reduce (fn [acc [op args]] `(if-not (nil? ~acc) (~op ~acc ~@args))) init fns)) I did not have a need for as--like functionality. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: nested map destructuring
On Tue, Mar 19, 2013 at 2:58 PM, Jim - FooBar(); jimpil1...@gmail.com wrote:
awsome!...the full thing actually is {{:keys [w1 w2 w3]} :weights u
:uni-probs b :bi-probs t :tri-probs}
You might also consider
{:keys [uni-probs bi-probs tri-probs]} {:keys [w1 w2 w3]} :weights}
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Beginners question - emacs compiling tests
It looks like you're missing (ns ...) forms at the top of each file.
That tutorial doesn't show them, but lein would have generated them
for you when it generated the project. The key element is that your
test file should have a (:use clojure.test) in the (ns) form, which is
what allows you to use clojure.test/deftest without
namespace-qualification.
On Tue, Mar 19, 2013 at 2:12 PM, tyaakow tyaa...@gmail.com wrote:
I'm going through clojure emacs tutorial from clojure-doc.org, and
when compiling
the test as suggested, i get following output in emacs nrepl:
clojure.lang.Compiler$CompilerException:
java.lang.RuntimeException: Unable to resolve symbol: deftest in this
context, compiling:(/home/jakov/dev/PROJECTS/clojure/test2/test/test2/
core_test.clj:1)
Compiler.java:6281 clojure.lang.Compiler.analyze
Compiler.java:6223 clojure.lang.Compiler.analyze
Compiler.java:3497 clojure.lang.Compiler
$InvokeExpr.parse
Compiler.java:6457 clojure.lang.Compiler.analyzeSeq
Compiler.java:6262 clojure.lang.Compiler.analyze
Compiler.java:6223 clojure.lang.Compiler.analyze
Compiler.java:6515 clojure.lang.Compiler.eval
Compiler.java:6952 clojure.lang.Compiler.load
Compiler.java:6912 clojure.lang.Compiler.loadFile
RT.java:307 clojure.lang.RT$3.invoke
NO_SOURCE_FILE:1 user/eval42
Compiler.java:6511 clojure.lang.Compiler.eval
Compiler.java:6477 clojure.lang.Compiler.eval
core.clj:2797 clojure.core/eval
main.clj:245 clojure.main/repl[fn]
main.clj:266 clojure.main/repl[fn]
main.clj:266 clojure.main/repl
RestFn.java:1096 clojure.lang.RestFn.invoke
interruptible_eval.clj:56
clojure.tools.nrepl.middleware.interruptible-eval/evaluate[fn]
AFn.java:159 clojure.lang.AFn.applyToHelper
AFn.java:151 clojure.lang.AFn.applyTo
core.clj:601 clojure.core/apply
core.clj:1771 clojure.core/with-bindings*
RestFn.java:425 clojure.lang.RestFn.invoke
interruptible_eval.clj:41
clojure.tools.nrepl.middleware.interruptible-eval/evaluate
interruptible_eval.clj:171
clojure.tools.nrepl.middleware.interruptible-eval/interruptible-
eval[fn]
core.clj:2278 clojure.core/comp[fn]
interruptible_eval.clj:138
clojure.tools.nrepl.middleware.interruptible-eval/run-next[fn]
AFn.java:24 clojure.lang.AFn.run
ThreadPoolExecutor.java:895
java.util.concurrent.ThreadPoolExecutor$Worker.runTask
ThreadPoolExecutor.java:918
java.util.concurrent.ThreadPoolExecutor$Worker.run
Thread.java:662 java.lang.Thread.run
Caused by: java.lang.RuntimeException: Unable to resolve symbol:
deftest in this context
Util.java:170 clojure.lang.Util.runtimeException
Compiler.java:6766 clojure.lang.Compiler.resolveIn
Compiler.java:6710 clojure.lang.Compiler.resolve
Compiler.java:6671
clojure.lang.Compiler.analyzeSymbol
Compiler.java:6244 clojure.lang.Compiler.analyze
To me, it seems like this line is crucial in the nrepl error output:
Caused by: java.lang.RuntimeException: Unable to resolve symbol:
deftest in this context
Anyway, i am really a clojure emacs noob, and I dont have much clue
here.
All the emacs slime clojure stuff is installed, `leiningen2` is
installed, java is oracle java 1.6, emacs is emacs 24, and when I run
lein test in projects directory, it goes without errors.
Can anyone help me?
My core_test.clj file:
(deftest pairs-of-values
(let [args [--server localhost
--port 8080
--environment production]]
(is (= {:server localhost
:port 8080
:environment production}
(parse-args args)
My core.clj file:
(defn parse-args [args]
{})
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit
Re: Exception propagation design in Clojure web APIs.
One argument against using exceptions for commonplace occurrences (like
invalid user input) is that the structure of the code may make it difficult
to see where those things can pop up, which can lead to misunderstanding
and introduction of bugs.
Even with Java's checked exceptions, where a certain method may be declared
to throw a custom ValidationException or whatever, you can't see from the
calling code which methods can throw one. You have to go look at the
signatures of all called methods looking for them. (Or more likely you
comment out the catch clause and see which calls your IDE underlines in
red.) Using standard control-flow constructs make branch-points explicit.
On Mar 19, 2013 8:26 PM, Dave Sann daves...@gmail.com wrote:
That should have been why is 1 preferable over 2...
On Wednesday, 20 March 2013 12:24:12 UTC+11, Dave Sann wrote:
I am interested in this view that exceptions are an anti pattern. I have
heard it voiced before.
I am not sure that I understand why.
As I see it you have a choices:
1. Handle in the result - and test this result repeatedly all the way
back to the caller
2. Handle out of band - Throw an exception, allow the stack to unwind
and catch where it matters
[And maybe - but I am not very knowledgeable on this and it won't work
today on the JVM anyway
3. Use continuation passing style with TCO to shortcut the return to
follow an exception path]
So, ignoring 3.
Why is 2 preferable over 1? There are certainly pros and cons.
Dave
On Wednesday, 20 March 2013 09:42:11 UTC+11, James Reeves wrote:
I'd argue that using exceptions for control flow is something of an
anti-pattern, even in Java.
In this case a better mechanism might be to use polymorphism. For
instance:
(defprotocol Validatable
(validation-errors [x] Return the validation errors for x.))
(defn valid? [x]
(empty? (validation-errors x)))
Then you can define a general function to validate and store that item
in a database:
(defn store-valid [db x]
(if (valid? x)
(store db x)
(validation-error-response x)))
- James
On 19 March 2013 16:43, Julien Dreux julien...@gmail.com wrote:
Hi all,
Coming from a Java background, I am having a hard time understanding
how validation error propagation should work in clojure web APIs.
To be clear, this is similar to how my Java web service would be setup:
/** Method that validates the model, accesses the DB. If something went
wrong, throw an exception */
public void validateAndCreateUser(User u) throws ValidationException,
EmailAlreadyInUseException, ... {
...
if(...) {
throw new ValidationException(fieldName)**;
} else if (...) {
throw new EmailAlreadyInUseException(u.**getEmail());
}
}
/** Endpoint method, catches formats the exceptions thrown by the db
method. **/
@POST(/api/user/create)
public Response createUser (User u) {
..
try{
validateAndCreateUser(u);
return Response.ok();
} catch (Exception e) {
return generateExceptionResponse(e); //Method that maps exceptions
to responses.
}
}
For all of Java's clunkiness, this had the benefit of not having to
write tons of if/else statements for validation handling. Exception were
just thrown from anywhere, bubbling back up to inital call, and if not
handled in the endpoint method, a specialized class mapped them into a
proper response. The exceptions contained all the information needed to
generate 'rich' error messages back to the client.
Being a Clojure newbie, I wonder what a good pattern is for a similar
situation. So far, I have a method that validates models based on a schema,
that returns
{:success true}
or
{:success false :errors [error 1 error 2 ...]}
But I don't know how to avoid having to write if/else conditions of the
sort in each function between my endpoint and db functions.
(if (validation :success)
(follow-normal-path)
(handle-validation-errors validation))
Any guidance appreciated.
Cheers,
Julien
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@googlegroups.com.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
--
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
Re: Clj-record
On Tue, Sep 1, 2009 at 4:43 PM, Luc Prefontainelprefonta...@softaddicts.ca wrote: Hi John, Clj-record will make its way into production in a couple of weeks. It's been working flawlessly in high volume tests here. Hi Luc, That's great to hear. I recently set up a Google Group for clj-record, so you may want to sign up. http://groups.google.com/group/clj-record-dev It's very low-volume. In fact, it's basically no-volume. :) Thanks for the encouragement. -hume. -- http://elhumidor.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: ANN: libraries promoted from contrib to clojure
There may already have been a discussion about this in IRC, but I would have loved to see the 'are' macro continue to support the old syntax (maybe with deprecation warnings) as well as the new until after 1.1 is released. This change makes it relatively expensive for any library with a significant test suite that uses 'are' to keep testing with both the current release and the current snapshot of clojure and contrib. On Thu, Jun 25, 2009 at 10:40 PM, Stuart Hallowaystuart.hallo...@gmail.com wrote: ... Also, the signature and implementation of test/are has changed, and is now more idiomatic. For example: (deftest test-count (are [x y] (= x y) ; instead of (are (= _1 _2)) (count nil) 0 (count ()) 0 (count '(1)) 1 (count '(1 2 3)) 3 ; etc. -- http://elhumidor.blogspot.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: Interest in creating a NYC Clojure user group?
On Thu, Jun 4, 2009 at 12:09 PM, Eric Thorsenethor...@enclojure.org wrote: what kind of interest there might be in creating a Clojure user group in the NY metro area to meet up in Manhattan once a month to discuss all things Clojure. I'd make an effort to attend monthly Clojure meetings in NYC. -- http://elhumidor.blogspot.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: Google App Engine - best workflow
On Fri, May 15, 2009 at 6:02 AM, Kees-Jochem Wehrmeijer henc...@gmail.com wrote: beyond my skill level. At first I tried to start a swank server from my servlet, but that failed because GAE doesn't allow you to open sockets. By decompiling and disabling that, I could probably work This still wouldn't give you a REPL running in the dev server, but for messing around with datastore stuff interactively you can call appengine-clj.test-utils/ds-setup [1] from a REPL which will create an in-memory datastore. I've used this with vimclojure with some success. (Occasionally it will tell me I don't have an app registered for the current thread, and I have to call ds-setup again. I assume this has to do with something multi-threaded happening in the nailgun server vimclojure uses, but I haven't delved into it.) -hume. [1] http://github.com/duelinmarkers/appengine-clj/blob/master/src/appengine_clj/test_utils.clj#L9 -- http://elhumidor.blogspot.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 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.main always exits with code 0
Submitted as http://code.google.com/p/clojure/issues/detail?id=106 --~--~-~--~~~---~--~~ 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 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] Compiling Clojure applications using Ant
On Sat, Apr 11, 2009 at 3:49 PM, Richard Lyman richard.ly...@gmail.com wrote:
http://www.lithinos.com/Compiling-Clojure-applications-using-Ant.html
What do you guys think?
-Rich
It's a bit simpler to use clojure.lang.Compile as a main class.
Here's the relevant bit from one of my build.xmls:
target name=compile depends=clean,init
java classname=clojure.lang.Compile
classpathref=project.classpath
fork=true
failonerror=true
classpath path=${src.dir} /
sysproperty key=clojure.compile.path value=${classes.dir} /
arg value=clj-record.boot /
/java
/target
http://github.com/duelinmarkers/clj-record/blob/c8235e7d854c0049a785d7773665cb6c62efb024/build.xml#L30
I strongly recommend failonerror=true so that your build will abort
if compilation fails. (If you stick with the clojure.main -e
(compile... approach I think you'll find clojure.main doesn't exit
with an error code, so it won't work. There's another recent thread
about that and I'm planning to open an issue and submit a patch for it
when I have a chance. clojure.lang.Compile does exit with an error
when compilation fails, so the above will fail a build appropriately.)
Also, I'd recommend being clearer in describing the app variable. It
will need to be a Clojure namespace that when loaded will (one way or
another) load in all of your Clojure code. If someone is building a
library, it's relatively likely there is no such namespace.
-hume.
--
http://elhumidor.blogspot.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
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.main always exits with code 0
Rich, Can I submit an issue and patch for this? I have a CA on file. Thanks. -hume. On Sun, Apr 5, 2009 at 8:15 PM, John D. Hume duelin.mark...@gmail.com wrote: Currently it does this: (try the good stuff ... (catch Exception e (.printStackTrace e *err*))) (flush)) Instead I'd like it to: (try the good stuff ... (flush) (catch Exception e (flush) (throw e))) Basically just let Java do what Java does when an unhandled exception is thrown (after flushing *out* to keep from confusing people). I know a lot of what's in clojure.main is meant to be useful for embedding in larger programs, but it doesn't look to me like the main function is intended for that. -- http://elhumidor.blogspot.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 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: Is there a simple Clojure data schema/validation library?
On Thu, Apr 9, 2009 at 11:58 AM, samppi rbysam...@gmail.com wrote: I've been whipping up a simple schema library for validating Clojure data based on their tags, but I'm worried that what I'm doing might be redundant with an already existing library. Is there something, such as in clojure-contrib, that can do things similar to the code below There's some similarity with the validation stuff in clj-record[1], but that's about DB persistence. (It also doesn't use metadata.) I was thinking about trying to tease clj-record apart so it could be backed by AppEngine's API for BigTable. Maybe I should also consider non-persistence-related uses of the parts where it makes sense. -hume. [1] http://github.com/duelinmarkers/clj-record/tree/master -- http://elhumidor.blogspot.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 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 on Google AppEngine
As predicted, Google has now released Java support for AppEngine. I was lucky enough to get an early look, which I dedicated entirely to Clojure. Here's a writeup: http://elhumidor.blogspot.com/2009/04/clojure-on-google-appengine.html Have fun! -hume. -- http://elhumidor.blogspot.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 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.main always exits with code 0
Earlier today I was surprised to notice that some test-is unit tests I
was running from Ant failed, but it still reported BUILD SUCCESSFUL. I
figured I'd forgotten to include failonerror=true in the java task,
but it was there. So I played around and found that
$ java -cp clojure.jar clojure.main -e garbage
java.lang.Exception: Unable to resolve symbol: garbage in this context
(NO_SOURCE_FILE:0)
at clojure.lang.Compiler.analyze(Compiler.java:4330)
...etc
$ echo $?
0
Likewise with a script. This seems like a bug. Would it be acceptable
to change clojure.main/main as follows?
Currently it does this:
(try
the good stuff ...
(catch Exception e
(.printStackTrace e *err*)))
(flush))
Instead I'd like it to:
(try
the good stuff ...
(flush)
(catch Exception e
(flush)
(throw e)))
Basically just let Java do what Java does when an unhandled exception
is thrown (after flushing *out* to keep from confusing people). I know
a lot of what's in clojure.main is meant to be useful for embedding in
larger programs, but it doesn't look to me like the main function is
intended for that.
Thanks.
-hume.
--
http://elhumidor.blogspot.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
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
-~--~~~~--~~--~--~---
