Re: How to exclude compile-time dependencies from uberjar?
Hi
provided dependencies should work for you, this is from my project.clj :
:profiles {:provided {:dependencies [[org.apache.storm/storm-core
0.9.4]]}}
On Wed, Jul 1, 2015 at 5:14 PM, Robin Heggelund Hansen skinney...@gmail.com
wrote:
All suggestions made the dependencies unavailable when running `lein
uberjar` which means the project won't build :/
--
You 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.
--
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 received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Introducing Yagni, a Leiningen plugin for finding unused code
I may be putting words in Stuart's mouth here, but what I believe he meant is that it would be great if Yagni were just a Clojure library with a function you could call passing it everything it needs (probably source paths and entry point details), and ideally returning the results as data. Then the lein plugin could just call that function and print the results, but other tooling which might not use lein could also take advantage of Yagni. Great work BTW, Yagni looks very cool. I'm planning to implement something similar in Cursive but I'll be using the IntelliJ infrastructure to do it. The idea is the same, though. On 2 July 2015 at 06:31, W. David Jarvis venant...@gmail.com wrote: Hey Stuart - Could you clarify what you meant your comment? I'm not sure I understand what you mean by a pure function in this context. - David On Tue, Jun 30, 2015 at 8:10 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: Nice. It would be really cool if run-yagni was a pure function of source-paths and mains. This would make the dependency on lein optional and allow adoption on e.g. mainland Java projects. Stu On Tue, Jun 30, 2015 at 5:44 AM, Yehonathan Sharvit vie...@gmail.com wrote: Yagni ignore `cljs` files. I have opened an issue here: https://github.com/venantius/yagni/issues/26 On Thu, Jun 25, 2015 at 1:53 AM, W. David Jarvis venant...@gmail.com wrote: Indeed. I'd argue it's better not to have unused code in the codebase in the first place, regardless of what the Closure compiler does to help when it comes to compiling assets. I haven't tested this with cljs projects, but on the face of it I don't see why Yagni's methodology wouldn't work. If you get a chance to give it a try I'd love the feedback :) On Wednesday, June 24, 2015 at 2:58:14 PM UTC-7, juan.facorro wrote: That's a good point. On Wednesday, June 24, 2015 at 6:53:43 PM UTC-3, Fluid Dynamics wrote: FMIIW, but I think they serve orthogonal purposes. Google Closure finds code (mostly library parts your program doesn't use) that your particular program doesn't need and omits it from the build to save disk and bandwidth. Yagni finds obsolete code that is no longer reached in your program or from *any* public entry point to your library (whether a particular program uses that entry point or not) and issues warnings, so you know that either something is maintenance deadweight or you have a bug because you *meant* to call it somewhere but forgot, or it's become accidentally shadowed or something. -- You 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/fGhjG70w0_U/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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. -- You 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/fGhjG70w0_U/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- venanti.us 203.918.2328 -- You received this message because you are subscribed to the Google
Re: zipmap different ordering in 1.7
That was exactly what i'm doing to fix it. I didnt care about the actual
order but assumed the order was going to stay the same. Bad assumption.
Thank you all for the feedback.
Op donderdag 2 juli 2015 03:06:00 UTC+2 schreef Fluid Dynamics:
On Wednesday, July 1, 2015 at 3:54:03 PM UTC-4, Jo Geraerts wrote:
Hey,
I when i tried to run my program with the shiny new 1.7, it broke. I have
traced it down to the fact that zipmap (
https://github.com/clojure/clojure/blame/master/src/clj/clojure/core.clj#L2940)
does returns the keys in a different order than i'm used to.
e.g clojure 1.6:
nREPL server started on port 52315 on host 127.0.0.1 - nrepl://
127.0.0.1:52315
REPL-y 0.3.5, nREPL 0.2.7
Clojure 1.6.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_40-b26
Docs: (doc function-name-here)
(find-doc part-of-name-here)
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
Results: Stored in vars *1, *2, *3, an exception in *e
user= (zipmap [:a :b] [:c :d])
{:b :d, :a :c}
Whereas clojure 1.7 does:
nREPL server started on port 52193 on host 127.0.0.1 - nrepl://
127.0.0.1:52193
REPL-y 0.3.5, nREPL 0.2.7
Clojure 1.7.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_40-b26
Docs: (doc function-name-here)
(find-doc part-of-name-here)
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
Results: Stored in vars *1, *2, *3, an exception in *e
user= (zipmap [:a :b] [:c :d])
{:a :c, :b :d}
As i'm using the keys function later on these values as a multimethod
dispatch function, things break.
It's rather trivial to change my program with the new ordering, but i was
wondering if the ordering of the keys of the returned map is part of the
contract.
When one would need more context about the actual code, the usage of the
zipmap can be found here at
https://github.com/jgeraerts/imageresizer/blob/master/src/net/umask/imageresizer/urlparser.clj#L19
.
The multimethod dispatch
https://github.com/jgeraerts/imageresizer/blob/master/src/net/umask/imageresizer/resizer.clj#L15
The tests break with these kinds of exceptions:
ERROR in (test-resizer) (MultiFn.java:156)
expected: (= [200 [200 200]] (run-resizer size/200x200/rose-cmyk.tiff))
20:31:05.179 [main] WARN net.umask.imageresizer.resizer - image not
found for uri size/200x200/nonexisting
actual: java.lang.IllegalArgumentException: No method in multimethod
'scale' for dispatch value: (:width :height)
at clojure.lang.MultiFn.getFn (MultiFn.java:156)
clojure.lang.MultiFn.invoke (MultiFn.java:233)
I'm glad to hear your feedback.
Key order for (non-sorted) maps is not guaranteed, but there is an easy
fix: pour the result of keys into a set, e.g. (into #{} (keys my-map)), and
use #{:width :height} e.g. as your dispatch values. Then it will work
independently of the vagaries of key ordering.
--
You 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: (flatten non-sequential) has a surprising result
Hi Pablo,
I think you're right. Have a look at flatten source
(defn flatten
Takes any nested combination of sequential things (lists, vectors,
etc.) and returns their contents as a single, flat sequence.
(flatten nil) returns an empty sequence.
{:added 1.2
:static true}
[x]
(filter (complement sequential?)
(rest (tree-seq sequential? seq x
it is the rest function that causes this behavior and it seems to be just
an optimization to avoid filtering the first element of tree-seq that is
known to be the whole sequence. A simpler definition of flatten seems to
have the behavior you expected.
(defn flatten1 [x] (filter (complement sequential?) (tree-seq sequential?
seq x)))
Il giorno mercoledì 1 luglio 2015 13:55:28 UTC+2, J. Pablo Fernández ha
scritto:
Hello Clojurists,
Today I was surprised by the result of (flatten 1) which is '(). I was
expecting '(1) or an error. Talking in some other people in #clojure @
clojurians.net, not everybody agrees that '(1) is a good result but that
'() is somewhat surprising. Would it be better if it raised an error when
the attribute is not sequential?
--
You 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: (flatten non-sequential) has a surprising result
Yes, reading the source code and trying to understand why rest was being
called there is how I came up with this case.
On 2 July 2015 at 07:54, icamts ica...@gmail.com wrote:
Hi Pablo,
I think you're right. Have a look at flatten source
(defn flatten
Takes any nested combination of sequential things (lists, vectors,
etc.) and returns their contents as a single, flat sequence.
(flatten nil) returns an empty sequence.
{:added 1.2
:static true}
[x]
(filter (complement sequential?)
(rest (tree-seq sequential? seq x
it is the rest function that causes this behavior and it seems to be just
an optimization to avoid filtering the first element of tree-seq that is
known to be the whole sequence. A simpler definition of flatten seems to
have the behavior you expected.
(defn flatten1 [x] (filter (complement sequential?) (tree-seq sequential?
seq x)))
Il giorno mercoledì 1 luglio 2015 13:55:28 UTC+2, J. Pablo Fernández ha
scritto:
Hello Clojurists,
Today I was surprised by the result of (flatten 1) which is '(). I was
expecting '(1) or an error. Talking in some other people in #clojure @
clojurians.net, not everybody agrees that '(1) is a good result but that
'() is somewhat surprising. Would it be better if it raised an error when
the attribute is not sequential?
--
You 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/L6yf6iFPqe8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
J. Pablo Fernández pup...@pupeno.com (http://pupeno.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/d/optout.
Re: [ANN] `comidi`: a committee approach to defining HTTP routes
On Wednesday, July 1, 2015 at 12:57:01 PM UTC+1, Dan Kersten wrote: Regarding the Whats next in the README: *looking into swagger integration. I could swear I found some bidi-swagger bindings somewhere a while back, but am not finding them at the moment* Could you perhaps be thinking of the Yada swagger integration? http://yada.juxt.pro/user-guide.html#Swagger yada.swagger is designed to be used with bidi. https://github.com/juxt/yada/blob/master/src/yada/swagger.clj Maybe so! Will definitely look that over before doing anything else. Appreciate the link! On Wed, 1 Jul 2015 at 10:45 Chris Price ch...@puppetlabs.com javascript: wrote: Hiya. We really like the syntax of compojure for defining HTTP routes, but have had some trouble with use cases where we'd really like to be able to introspect the route tree, and aren't able to do so because the nested functions are pretty opaque. After spending some time trying to workaround that, and giving up, we decided to look into bidi, which has been awesome. The data-driven route tree is really, really useful. However, a wholesale port of all of our existing apps directly from compojure to bidi seemed daunting. Enter `comidi`: https://github.com/puppetlabs/comidi This is a small library that uses bidi to build up route trees, but provides a compojure-like syntax for defining the routes, and uses compojure's render capabilities to support flexible syntax for specifying your individual handlers for each route. We've also got a related project that integrates comidi with our Trapperkeeper framework and the dropwizard metrics library, to give you middleware that will automatically track request metrics for each route in your bidi/comidi route tree. This is all a work in progress: notably, we had built up some prismatic schemas around the route structures, but since the latest release of bidi ships with its own schemas, we'll probably try to upgrade to that and reconcile the differences soon. We also have some plans for improving the ability to wrap middleware around the route tree at various levels, and to look into some ring-swagger integration soon. -- 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 javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You 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.
{ANN} clj-archaius releases: wrapper for netflix archaius
Hi,all I create a new project https://github.com/leancloud/clj-archaius that wraps netflix https://github.com/Netflix/archaius archaius https://github.com/Netflix/archaius library for configuration management. It's really simple to use in your project,i hope it can help someone that is using netflix archaius lib. -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] `comidi`: a committee approach to defining HTTP routes
On Wednesday, July 1, 2015 at 4:35:35 PM UTC+1, Daniel Jomphe wrote: Chris, this is definitely interesting. Quickly pluggable metrics swagger trapperkeeper componentization sure are useful integrations. Doing a quick review, it surprised me a bit how many dependencies you brought into comidi https://github.com/puppetlabs/comidi/blob/master/project.clj [dependencies]. I *believe* that the only real deps there are the bidi/compojure ones, and that the rest are just there to try to resolve transitive dependency conflicts (we use lein's :pedantic? flag). I will double-check that, though. This looks more like a pragmatic, compromise integration library than a pure new offer (just like you said you need at Puppet Labs). That's definitely a fair characterization! Nevertheless, since you deviate from Compojure's API, I was very surprised to still see you depend on it. And then I remind myself that you're in there for meaningful, but quick, wins. The compojure dependency is because I still found Compojure's rendering capabilities to be really useful, and didn't want to re-invent them. But it is a compromise to have a dependency on both, to be sure. There was a discussion between most of the authors of the popular routing libraries when Silk was introduced, including bidi's Malcolm, which came to be very interesting too. When you titled `comidi` as being a committee approach to defining HTTP routes, I wondered if you were following up to that discussion. Here's a link I kept to the middle of it https://groups.google.com/forum/#!searchin/clojure/silk$20bidi/clojure/D95anPmhNhU/X7P53cGbfZMJ [discussion]. Yes, I did read that discussion before working on this stuff. In an ideal world or with a greenfield application, I think we might have just used bidi or silk directly (and, it is a goal of mine to try to make sure that our metrics stuff will work on plain-ole-bidi routes just as well as it does on comidi routes), but we have a *lot* of existing services built using compojure. In order to be able to re-use our metrics stuff across all of those existing services, the only realistic option was to try to make it as simple as possible to migrate from a compojure route structure to a bidi-backed one. In any case, thanks for contributing to this field. np, thanks for the feedback! [dependencies]: https://github.com/puppetlabs/comidi/blob/master/project.clj [discussion]: https://groups.google.com/forum/#!searchin/clojure/silk$20bidi/clojure/D95anPmhNhU/X7P53cGbfZMJ On Wednesday, July 1, 2015 at 5:45:40 AM UTC-4, Chris Price wrote: Hiya. We really like the syntax of compojure for defining HTTP routes, but have had some trouble with use cases where we'd really like to be able to introspect the route tree, and aren't able to do so because the nested functions are pretty opaque. After spending some time trying to workaround that, and giving up, we decided to look into bidi, which has been awesome. The data-driven route tree is really, really useful. However, a wholesale port of all of our existing apps directly from compojure to bidi seemed daunting. Enter `comidi`: https://github.com/puppetlabs/comidi This is a small library that uses bidi to build up route trees, but provides a compojure-like syntax for defining the routes, and uses compojure's render capabilities to support flexible syntax for specifying your individual handlers for each route. We've also got a related project that integrates comidi with our Trapperkeeper framework and the dropwizard metrics library, to give you middleware that will automatically track request metrics for each route in your bidi/comidi route tree. This is all a work in progress: notably, we had built up some prismatic schemas around the route structures, but since the latest release of bidi ships with its own schemas, we'll probably try to upgrade to that and reconcile the differences soon. We also have some plans for improving the ability to wrap middleware around the route tree at various levels, and to look into some ring-swagger integration 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/d/optout.
Re: Different macro definitions via reader conditionals?
@Mike: Great post. I think you should make it more explicit that the :cljs branch of the macro is never used on Clojure and CLJS/JVM. Kind regards, Leon. On Thursday, July 2, 2015 at 3:20:17 PM UTC+2, Mike Fikes wrote: I’m interested in whether there is a nice answer to this as well. FWIW, I was recently pondering a closely related subject—portability that additionally extends to bootstrapped ClojureScript: http://blog.fikesfarm.com/posts/2015-06-19-portable-macro-musing.html (Hoping things don’t become excessively combinatorial.) - Mike On Jul 2, 2015, at 8:09 AM, Michael Sperber spe...@deinprogramm.de javascript: wrote: I'd like to define a macro differently for Clojure and for ClojureScript. Is there a way to do this via reader conditionals? (My mind boggles.) Regards, Mike -- 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 javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Different macro definitions via reader conditionals?
It seems like the only way is to define two macros and call the desired one using reader conditionals. On Thursday, July 2, 2015 at 2:09:55 PM UTC+2, Michael Sperber wrote: I'd like to define a macro differently for Clojure and for ClojureScript. Is there a way to do this via reader conditionals? (My mind boggles.) Regards, Mike -- You 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.
Different macro definitions via reader conditionals?
I'd like to define a macro differently for Clojure and for ClojureScript. Is there a way to do this via reader conditionals? (My mind boggles.) Regards, Mike -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Different macro definitions via reader conditionals?
I’m interested in whether there is a nice answer to this as well. FWIW, I was recently pondering a closely related subject—portability that additionally extends to bootstrapped ClojureScript: http://blog.fikesfarm.com/posts/2015-06-19-portable-macro-musing.html http://blog.fikesfarm.com/posts/2015-06-19-portable-macro-musing.html (Hoping things don’t become excessively combinatorial.) - Mike On Jul 2, 2015, at 8:09 AM, Michael Sperber sper...@deinprogramm.de wrote: I'd like to define a macro differently for Clojure and for ClojureScript. Is there a way to do this via reader conditionals? (My mind boggles.) Regards, Mike -- You 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 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 mailto:clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout. -- You 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.
cider-error go to line
When I get a cider-error, it tells me line number within the function that raised the error, but is there an easy way to go to that line? Since the line number is within the function, I've been counting lines manually at the moment ... getting tired of this. Anyone has any suggestions? Thanks Ritchie -- You 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: clojure.core.match: AssertionError: Pattern row reuses wildcards
Use the :tx-data as a $-database!
The only pitfall is that the second position, the attribute, and all other
references (reference type) is just a reference to the attribute entity (a
long).
Let's say you find :db/txInstant to be 53, and :community/category to be
112 the query would look like
(q '[:find ?tx-eid . in $ :where [?tx-eid 53 _ ?tx-eid true] [_ 112 free
stuff ?tx-eid false]] tx-data-as-database)
If this query returns the ?tx-eid, and not nil, the contraints was
fulfilled - test passed.
Given that this is unit testing and performance is probably not a big
issue, maybe it would be possible to write a function generating a datomic
query like the one above, but with conveniences like it automatically
inlines the attribute-entids (or extends the query to automatically looking
them up using some reference to the db with the current schema installed).
Given that Datomic compiles every new query that is not parameterized this
could be quite heavy if it was used in production.
But in short, you can query the tx-data using datalog, the only pitfall is
that datoms are mostly primitives which must be looked up in the datomic db
they came from. I think datoms have a reference to the database they came
from, but I don't know how to use that fact.
It's full of stars.
/Linus
On Wednesday, July 1, 2015 at 9:47:07 PM UTC+2, Alan Thompson wrote:
Hi - I am trying to write some unit tests for Datomic using core.match to
keep things succinct. I was hoping to use a match pattern like this:
[ {:e tx-eid :a :db/txInstant:v _ :tx tx-eid
:added true}
{:e _ :a :community/category :v free stuff :tx tx-eid
:added false} ]
to show that the transaction EID (tx-eid) shows up in 3 places in the
datoms result of a transaction. However, I am getting the error:
Exception in thread main java.lang.AssertionError: Pattern row 1:
Pattern row reuses wildcards in [[{:e tx-eid, :a :db/txInstant, :v _, :tx
tx-eid, :added true} {:e _, :a :community/category, :v free stuff, :tx
tx-eid, :added false}]]. The following wildcards are ambiguous: tx-eid.
There's no guarantee that the matched values will be same. Rename the
occurrences uniquely.,
So I am apparently unable to use core.match in the way I was hoping. Are
there any workarounds to this problem?
Thanks,
Alan
--
You 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: cider-error go to line
This is a problem on nREPL, not CIDER. See http://dev.clojure.org/jira/browse/NREPL-59 for details. There aren't any real solutions to this, other than fixing nREPL, but we're considering some workarounds (e.g. trying to find the definition using a regular expression and using the relative position from there) https://github.com/clojure-emacs/cider/issues/1175 But as I said NREPL-59 has to be fixed eventually, as this is killing us (and everyone using nREPL), so consider dropping by the issue and voicing your support for the proposed patch. On 3 July 2015 at 02:44, Ritchie Cai ritchie...@gmail.com wrote: When I get a cider-error, it tells me line number within the function that raised the error, but is there an easy way to go to that line? Since the line number is within the function, I've been counting lines manually at the moment ... getting tired of this. Anyone has any suggestions? Thanks Ritchie -- You 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. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Introducing Yagni, a Leiningen plugin for finding unused code
Thanks Colin, that is exactly it. On Thu, Jul 2, 2015 at 2:27 AM, Colin Fleming colin.mailingl...@gmail.com wrote: I may be putting words in Stuart's mouth here, but what I believe he meant is that it would be great if Yagni were just a Clojure library with a function you could call passing it everything it needs (probably source paths and entry point details), and ideally returning the results as data. Then the lein plugin could just call that function and print the results, but other tooling which might not use lein could also take advantage of Yagni. Great work BTW, Yagni looks very cool. I'm planning to implement something similar in Cursive but I'll be using the IntelliJ infrastructure to do it. The idea is the same, though. On 2 July 2015 at 06:31, W. David Jarvis venant...@gmail.com wrote: Hey Stuart - Could you clarify what you meant your comment? I'm not sure I understand what you mean by a pure function in this context. - David On Tue, Jun 30, 2015 at 8:10 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: Nice. It would be really cool if run-yagni was a pure function of source-paths and mains. This would make the dependency on lein optional and allow adoption on e.g. mainland Java projects. Stu On Tue, Jun 30, 2015 at 5:44 AM, Yehonathan Sharvit vie...@gmail.com wrote: Yagni ignore `cljs` files. I have opened an issue here: https://github.com/venantius/yagni/issues/26 On Thu, Jun 25, 2015 at 1:53 AM, W. David Jarvis venant...@gmail.com wrote: Indeed. I'd argue it's better not to have unused code in the codebase in the first place, regardless of what the Closure compiler does to help when it comes to compiling assets. I haven't tested this with cljs projects, but on the face of it I don't see why Yagni's methodology wouldn't work. If you get a chance to give it a try I'd love the feedback :) On Wednesday, June 24, 2015 at 2:58:14 PM UTC-7, juan.facorro wrote: That's a good point. On Wednesday, June 24, 2015 at 6:53:43 PM UTC-3, Fluid Dynamics wrote: FMIIW, but I think they serve orthogonal purposes. Google Closure finds code (mostly library parts your program doesn't use) that your particular program doesn't need and omits it from the build to save disk and bandwidth. Yagni finds obsolete code that is no longer reached in your program or from *any* public entry point to your library (whether a particular program uses that entry point or not) and issues warnings, so you know that either something is maintenance deadweight or you have a bug because you *meant* to call it somewhere but forgot, or it's become accidentally shadowed or something. -- You 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/fGhjG70w0_U/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You 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. -- You 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/fGhjG70w0_U/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. --
