This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (113)
- # announcements (6)
- # beginners (18)
- # boot (294)
- # bristol-clojurians (3)
- # cider (90)
- # clojure (122)
- # clojure-berlin (42)
- # clojure-czech (1)
- # clojure-dev (19)
- # clojure-italy (4)
- # clojure-japan (5)
- # clojure-korea (10)
- # clojure-russia (1)
- # clojure-uk (5)
- # clojured (1)
- # clojurescript (179)
- # datomic (2)
- # editors (10)
- # indycljs (1)
- # jobs (1)
- # ldnclj (29)
- # off-topic (33)
- # onyx (11)
- # reagent (48)
- # yada (18)
Just wondering if there are any clojure wrappers over java 8 streams & lambda's etc...
sometimes I want to try out something with an existing library in a project that doesn't have that dependency to see how it works
alternatively maybe I should just keep a project where I have all the possible libraries in the world available and use that for trying out stuff instead
Oh, what I meant is, when doing dependency resolution, is lein assuming that it will work? so if someone is using clojure 1.7.0 will it just try to use my library or get an error, because my library claims 1.6.0?
Version specification with lein makes me a bit nerveous as it doesn’t have >= or ~= like gem/bundle in Ruby.
I should use the version 0.1.0-SNAPSHOT should be while developing, then, for release, I should switch that to 0.1.0 and then, when starting developing 0.2.0-SNAPSHOT?
@pupeno: and the get attached a timestamp and are refreshed daily by default if used as an attachment
@ordnungswidrig: yes, I’m currently developing 0.1.0-SNAPSHOT so, I should change that to 0.1.0 to release, and then change it to 0.2.0-SNAPSHOT to keep on developing. x-SNAPSHOT comes before x… or am I wrong here?
@andrewmcveigh: I’m familiar with semantic versioning. I actually wrote a blog post about it back when it was new. But this SNAPSHOT is not part of it, which is the confusing part.
lein-release will try to sign the git-tag, and the jar. If you’re wanting to release to http://clojars.org, you cannot ‘promote’ an unsigned release. How important that is, I guess it’s up to you.
It proves that the release is from you, so that could be important to consumers of the lib.
I have a namespace in which I would like to delegate some functions to another namespace, I'm doing that by simply defing a reference, like: (def a other-ns/a), there is any other way to do about this?
thanks @ragee, my only issue with the (def) solution is that Cursive doesn't follows this kind of definition nicely (when auto-completing, it displays as a simple var, instead of function with the expected arguments)
@ragee: I'm actually just writing an email to the cursive list asking if Cursive could follow those kind of alias automatically
@ragge: just letting you know, I tried ot manually set the metadata for the argslist and it didn't worked... so I think it wouldn't really matter me to use potemkin for that, hopefully Cursive can do the following in future
Playing with Vars is likely to confuse static analysis tools, and can have unexpected consequences with things like alter-var-root.
I’m guilty of having small namespaces. Trying to break that habit from the OO world. Going thru withdrawal syndrome.
@stuartsierra: so, in my case the aliases that I'm making are for a foreign namespace (datomic in this case), on my own namespaces I try to keep a small number, but on this case I wanted a namespace that has some datomic api functions + some utilities of mine (because what was happening is that all the times I was requiring both namespaces, datomic and my utils, with the aliases I can include only mine), any further suggestion here?
@wilkerlucio: That's confusing to someone who has to read your code, because they can't tell which functions are yours and which are part of the Datomic API.
I believe the risk of confusion greatly outweighs the "convenience" of a single namespace.
even in OO code, I hate it when I have to go deeper and deeper down the inheritance chain to find the code that is actually doing something.
importing vars (or creating aliases like this), I think, would lead to a similarly sour experience.
My biases may be different from yours. As a consultant, I spend a lot of time reading other peoples code, so I place a high value on being able to understand how a piece of code works just by reading it.
@stuartsierra: +1 - I wish developers understood the difference between encapsulation and abstraction - just moving stuff around really isn’t abstraction.
@stuartsierra: What I meant to say was that I don’t think that bias is that different, we all end up reading code, either our own 6 months later or our team mates. We should all have that bias
when implementing a protocol in another namespace do I have to (:import) it or is it sufficient to (:require the-ns :as the-ns) and then (defrecord Myrecord  the-ns/TheProtocol (…)))?
so in ns-1 I have (defprotocol AProtocol (say-hi [this])) what do I have to do in ns-2?
(I am running into intermittent errors with ‘No implementation of method X on protocol’ when reloading code)
in my project I like having to include a single namespace because it's happening often, and in my case I'm the only developer and this convenience is being very nice, maybe worth splitting later but I'll keep it there for now, but I understand your point on the understanding
@colin.yates: require is sufficient. the reloading issues could very well be that the protocol is being re-def'd but the record isn't. this is a known limitation of protocols (will try to find the google groups thread). one 'hacky' solution is to wrap protocols in a
defonce. Another is to keep all your protocols in a namespace that doesn't get reloaded.
Anyone knows why pprint doesn't return it's argument? It would make it so much convenient.
@colin.yates: Exactly. Or use the record constructor functions like ->Foo map->Foo, which are normal Vars.
@mateusz-fiolka: Probably because the typical use is at the REPL, where you don't want to see the non-pprinted value immediately after the pprinted one.
I have a situation where I have a seq of some zippers (sourced from XML) and in the event that the XML is erroneous, I want to catch the exception… I have a test in place to make this assertion about the behavior when supplied with faulty XML.
However, since the datastructure is lazy, I can't simply
(is (search/xml->maps xml)) since the error isn't encountered until the test tries to realize the data structure
(try <code producing zippers here> (catch Exception e <etc>)) code won't catch it at this point
I can get the test to pass if I force the data structure to be realized inside the
search/xml->maps function, but that's obviously suboptimal
and where the XML is in an unexpected format, those type casts could end up doing things like
you could plug in your own logic via the protocol here maybe? https://github.com/clojure/data.xml/blob/master/src/main/clojure/clojure/data/xml.clj#L73
so I'm trying to catch that exception, log it and continue with the rest of the parsing (since one sibling in the xml hierarchy shouldn't stop all the parsing)
under test, the structures stay lazy until something prompts them to be evaluated, at which point the exception occurs outside of where I'm catching the local exception at
yeah, I don't have to force it in the actual app code… I think it's a side-effect of how the
is macro works, but I'm not entirely sure
in practice, I don't know that it would be a terrible thing to force realization… but I hate to change app code to make a test work when I can see it behaving properly
again though, if you set the default uncaught exception handler, the exception will occur outside of where you're catching the local exception, but you could do something with it to make it visible to you
I have n sibling xml nodes where one of them has unexpected structure. I want to see that n-1 of them are as expected and n is just an empty version of the same representation
either it's too much simpler or I'm missing something… either way, I'll have to go look at it again.