Re: [Job spam] Write Clojure in your pajamas, for decent money in a pleasant company, remote pairing all the time
Why all that pesky Ruby? =D
On Tue, Nov 19, 2013 at 4:44 PM, Alexey Verkhovsky
alexey.verkhov...@gmail.com wrote:
On Monday, 18 November 2013 16:45:40 UTC-7, Tony Tam wrote:
If I sent you a like to a github profile that looked like yours (
https://github.com/alexeyv?tab=repositories), would I ever get an
answer? I mean, it's very probable that all your activity is going into
private repos.
I'd probably send you this link instead:
https://github.com/thoughtworks/cruisecontrol.rb and explain that the
peak of my open source activity happened before there was Github. And maybe
mention the whole wife/family/kids thing :)
Besides, I didn't say that stellar resume stands for nothing at all.
So, in short, the answer is yes. By the way, Tony, your Github looks a
heck of a lot better than mine.
Back to the original subject of the thread, it looks like either there is
more Clojure work than people with platform expertise, or Clojure is a
mostly South American phenomenon. One way or the other, South America is
the only place I've got any responses from so far. {puzzled}
--Alex
--
--
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: 2013 State of Clojure ClojureScript survey results
The increased # of questions probably also reduces survey conversion ... I ran out of time because it was so long, and had a lot of other things to do, so I didn't submit my entry this year. On Tue, Nov 19, 2013 at 7:09 PM, Sean Corfield seancorfi...@gmail.comwrote: Yes, the path separator is O/S dependent: user (import '(java.io File)) java.io.File user (reduce #(File. %1 %2) [one two .. three]) #File one/two/../three user (.getCanonicalFile (reduce #(File. %1 %2) [one two .. three])) #File /Developer/workspace/worldsingles/ws/model/clojure/worldsingles/one/three user (.getPath (reduce #(File. %1 %2) [one two .. three])) one/two/../three Note that .getCanonicalFile renders the file path relative to the directory in which the REPL's JVM instance was started. Sean On Tue, Nov 19, 2013 at 7:02 PM, Cedric Greevey cgree...@gmail.com wrote: On Tue, Nov 19, 2013 at 10:02 AM, James Reeves ja...@booleanknot.com wrote: I think in this case it's more a problem with the Java API, which the fs library wraps. Until Java 7, I don't think relative path normalisation existed in the core Java libraries. It didn't, and .toPath isn't in the 1.6 java.io.File class in particular. 1.6 gives you these options: user= (reduce #(File. %1 %2) [one two .. three]) #File one\two\..\three user= (.getCanonicalFile (reduce #(File. %1 %2) [one two .. three])) #File C:\Windows\System32\one\three user= (.getPath (reduce #(File. %1 %2) [one two .. three])) one\\two\\..\\three Of these only getCanonicalFile normalizes, but it also makes it absolute, treating it as having been relative to (on the Win32 box I tested it on) the OS system directory of all places. It *is* interesting that Ruby Pathname objects and Java File objects get printed very similarly by Ruby and Clojure, respectively. I assume that / will replace \ as the separator (and the base directory used by getCanonicalFile will vary) if the above is used on other operating systems' JVMs. -- -- 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. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: ANN 2 years of ClojureWerkz
Hi Michael, outstanding work, thanks for taking the lead on this effort and many thanks to all the contributors. Las Sent from my phone On Nov 20, 2013 12:13 AM, Bruce Durling b...@otfrom.com wrote: Michael, Congrats and keep on going. I love using your libraries. cheers, Bruce On Tue, Nov 19, 2013 at 11:05 PM, Michael Klishin michael.s.klis...@gmail.com wrote: A couple of weeks ago ClojureWerkz [1] turned two years old. We are at 29 projects (not including failed experiments) and kicking. There have been dozens of contributors, entire major releases brilliantly managed by people outside of our tiny core team, and a pretty high bar in project quality sustained [2] [3]. I think it's fair to say that there have been positive changes in the overall Clojure library ecosystem, hopefully in part due to how vocal we've been (102 blog posts on blog.clojurewerkz.org this year alone). These days many world famous institutions and companies we respect use various ClojureWerkz projects to power their products and internal tools. Needless to say, we did not plan for it in 2011. So thank you, both users and contributors. There are some new projects in the pipeline and our values do not change: documentation, sane release practices, ease of contributing and backwards compatibility. We love all that boring stuff. Here's to another few years! 1. http://clojurewerkz.org 2. http://blog.clojurewerkz.org/blog/2013/04/20/how-to-make-your-open-source-project-really-awesome/ 3. http://www.slideshare.net/michaelklishin/open-source-responsibly -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- 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. -- @otfrom | CTO co-founder @MastodonC | mastodonc.com See recent coverage of us in the Economist http://econ.st/WeTd2i and the Financial Times http://on.ft.com/T154BA -- -- 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.
core.async timeout channels are values - is this intended
Hi all,
I ran into a core.async behaviour that confused me a bit the other day. In
some of our systems, we need to fire different timeouts, perform actions
and schedule a new timeout. The problem is, that if the timeouts are of the
same number of ms, we can't distinguish them, and therefore not keep track
of and remove them from a set (at least not easily).
That sounds a bit fuzzy. Hopefully this spike will make it clearer what I'm
trying to say:
(require '[clojure.core.async :refer [chan timeout alts!! alts!]])
(= (chan) (chan))
;; false
(= (timeout 1) (timeout 2))
;; false
(= (timeout 1) (timeout 1))
;; true
(do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
;; only fires 3, the last channel in the map
The intended behaviour of the last loop is to print 1, 2 and 3 (not
necessarily in that order). However, the ch-v map will only contain one
key, as timeouts with the same duration are considered the same value. In
the real example, a new timeout with the same value should be scheduled
again, by being put in the map.
So, my questions are:
- Is this intended behaviour?
- Is there a different pattern for achieving the scheduling behaviour I'm
looking for?
Thanks for your help,
Thomas
--
--
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: Get OutOfMemoryError Java heap space when parsing big log file
hi,Mark, thanks for your assistance.
Now, i modified the function parse-recur as you said .
And the new parse-file function code is:
.
(with-open [rdr (io/reader file)]
(let [res (parse-recur *(line-seq rdr) *{});lines)
sorted
(into (sorted-map-by (fn [key1 key2]
(compare [(get res key2) key2]
[(get res key1) key1])))
res)]
(find-write-recur *(line-seq rdr) *sorted n)
))
..
Here is another problem, as you can see , in the parse-file function i
have called twice *(line-seq rdr) .*
The first is to get Top-N users' list, the second is try to split the top-n
users' record and store in separate log file.
But when i have second call , the *(line-seq rdr) *return nil !!
Seems like the read cursor is at the end of the file, how can i fix this
problem?
2013/11/20 Mark Engelberg mark.engelb...@gmail.com
Yeah, I see now that you're still holding on to the head because a name is
given to the line sequence in the functions that you call.
One option would be making parse-recur and related functions that take
lines as an input into a macro.
You could also try:
(defn parse-recur
[ls res]
(if ls
(recur (next ls)
(update-res res (first ls)))
res))
and calling (parse-recur (line-seq rdr) {})
This way, the recur goes back to the main function entry point and ls is
overwritten, so nothing is holding on to the head. Make similar changes to
the other functions.
On Tue, Nov 19, 2013 at 8:07 PM, Jiaqi Liu liujiaq...@gmail.com wrote:
sorry, i mean weird...
2013/11/20 Jiaqi Liu liujiaq...@gmail.com
hi,Mark ,thanks for your suggestion.
I modified the main function to :
;
(defn parse-file
[file n]
(with-open [rdr (io/reader file)]
(println 001 begin with open (type rdr))
(let [;lines (line-seq rdr)
*res (parse-recur (line-seq rdr))*;lines)
sorted
(into (sorted-map-by (fn [key1 key2]
(compare [(get res key2) key2]
[(get res key1) key1])))
res)]
(println Statistic result : res)
(println Sorted result : sorted)
;(println ... (type rdr))
;(find-write-recur lines sorted n)
*(find-write-recur (line-seq rdr) sorted n)*
)))
;
But it's wired , i got this error:
com.util= (parse-file ./log600w.log 3)
001 begin with open java.io.BufferedReader
com.util= *OutOfMemoryError GC overhead limit exceeded
java.util.regex.Pattern.matcher (Pattern.java:1088)*
2013/11/20 Mark Engelberg mark.engelb...@gmail.com
Looks like you're holding on to the head by giving a name (lines) to
the result of line-seq. Don't do that. Try:
(parse-recur (line-seq rdr))
On Tue, Nov 19, 2013 at 7:27 PM, Jiaqi Liu liujiaq...@gmail.comwrote:
Hi,all
I want to parse big log files using Clojure.
And the structure of each line record is
UserID,Lantitude,Lontitude,Timestamp.
My implemented steps are:
Read log file Get top-n user list
Find each top-n user's records and store in separate log file
(UserID.log) .
The implement source code :
;==
(defn parse-file
[file n]
(with-open [rdr (io/reader file)]
(println 001 begin with open )
(let [lines (line-seq rdr)
res (parse-recur lines)
sorted
(into (sorted-map-by (fn [key1 key2]
(compare [(get res key2) key2]
[(get res key1) key1])))
res)]
(println Statistic result : res)
(println Top-N User List : sorted)
(find-write-recur lines sorted n)
)))
(defn parse-recur
[lines]
(loop [ls lines
res {}]
(if ls
(recur (next ls)
(update-res res (first ls)))
res)))
(defn update-res
[res line]
(let [params (string/split line #,)
id (if ( (count params) 1) (params 0) 0)]
(if (res id)
(update-in res [id] inc)
(assoc res id 1
(defn find-write-recur
Get each users' records and store into separate log file
[lines sorted n]
(loop [x n
sd sorted
id (first (keys sd))]
(if (and ( x 0) sd)
(do (create-write-file id
(find-recur lines id))
(recur (dec x)
(rest sd)
(nth (keys sd) 1))
(defn find-recur
[lines id]
(loop [ls lines
res []]
(if ls
(recur (next ls)
(update-vec res id (first ls)))
res)))
(defn update-vec
[res id line]
(let [params (string/split line #,)
id_(if ( (count params) 1) (params 0) 0)]
Re: Get OutOfMemoryError Java heap space when parsing big log file
Create a fresh reader?
On Wed, Nov 20, 2013 at 1:13 AM, Jiaqi Liu liujiaq...@gmail.com wrote:
hi,Mark, thanks for your assistance.
Now, i modified the function parse-recur as you said .
And the new parse-file function code is:
.
(with-open [rdr (io/reader file)]
(let [res (parse-recur *(line-seq rdr) *{});lines)
sorted
(into (sorted-map-by (fn [key1 key2]
(compare [(get res key2) key2]
[(get res key1) key1])))
res)]
(find-write-recur *(line-seq rdr) *sorted n)
))
..
Here is another problem, as you can see , in the parse-file function i
have called twice *(line-seq rdr) .*
The first is to get Top-N users' list, the second is try to split the
top-n users' record and store in separate log file.
But when i have second call , the *(line-seq rdr) *return nil !!
Seems like the read cursor is at the end of the file, how can i fix this
problem?
2013/11/20 Mark Engelberg mark.engelb...@gmail.com
Yeah, I see now that you're still holding on to the head because a name
is given to the line sequence in the functions that you call.
One option would be making parse-recur and related functions that take
lines as an input into a macro.
You could also try:
(defn parse-recur
[ls res]
(if ls
(recur (next ls)
(update-res res (first ls)))
res))
and calling (parse-recur (line-seq rdr) {})
This way, the recur goes back to the main function entry point and ls is
overwritten, so nothing is holding on to the head. Make similar changes to
the other functions.
On Tue, Nov 19, 2013 at 8:07 PM, Jiaqi Liu liujiaq...@gmail.com wrote:
sorry, i mean weird...
2013/11/20 Jiaqi Liu liujiaq...@gmail.com
hi,Mark ,thanks for your suggestion.
I modified the main function to :
;
(defn parse-file
[file n]
(with-open [rdr (io/reader file)]
(println 001 begin with open (type rdr))
(let [;lines (line-seq rdr)
*res (parse-recur (line-seq rdr))*;lines)
sorted
(into (sorted-map-by (fn [key1 key2]
(compare [(get res key2) key2]
[(get res key1) key1])))
res)]
(println Statistic result : res)
(println Sorted result : sorted)
;(println ... (type rdr))
;(find-write-recur lines sorted n)
*(find-write-recur (line-seq rdr) sorted n)*
)))
;
But it's wired , i got this error:
com.util= (parse-file ./log600w.log 3)
001 begin with open java.io.BufferedReader
com.util= *OutOfMemoryError GC overhead limit exceeded
java.util.regex.Pattern.matcher (Pattern.java:1088)*
2013/11/20 Mark Engelberg mark.engelb...@gmail.com
Looks like you're holding on to the head by giving a name (lines) to
the result of line-seq. Don't do that. Try:
(parse-recur (line-seq rdr))
On Tue, Nov 19, 2013 at 7:27 PM, Jiaqi Liu liujiaq...@gmail.comwrote:
Hi,all
I want to parse big log files using Clojure.
And the structure of each line record is
UserID,Lantitude,Lontitude,Timestamp.
My implemented steps are:
Read log file Get top-n user list
Find each top-n user's records and store in separate log file
(UserID.log) .
The implement source code :
;==
(defn parse-file
[file n]
(with-open [rdr (io/reader file)]
(println 001 begin with open )
(let [lines (line-seq rdr)
res (parse-recur lines)
sorted
(into (sorted-map-by (fn [key1 key2]
(compare [(get res key2) key2]
[(get res key1) key1])))
res)]
(println Statistic result : res)
(println Top-N User List : sorted)
(find-write-recur lines sorted n)
)))
(defn parse-recur
[lines]
(loop [ls lines
res {}]
(if ls
(recur (next ls)
(update-res res (first ls)))
res)))
(defn update-res
[res line]
(let [params (string/split line #,)
id (if ( (count params) 1) (params 0) 0)]
(if (res id)
(update-in res [id] inc)
(assoc res id 1
(defn find-write-recur
Get each users' records and store into separate log file
[lines sorted n]
(loop [x n
sd sorted
id (first (keys sd))]
(if (and ( x 0) sd)
(do (create-write-file id
(find-recur lines id))
(recur (dec x)
(rest sd)
(nth (keys sd) 1))
(defn find-recur
[lines id]
(loop [ls lines
res []]
(if ls
(recur (next ls)
(update-vec res id (first ls)))
res)))
(defn update-vec
Re: Padding missing elements in a sequence of identical K/V maps
Thanks all. This just highlights one of the nice things about Clojure to
me - the code gets out of the way to allow the algorithm to shine through.
Lovely.
By the way, this implementation is closest to my initial although I didn't
use juxt at the repl, but I did lose my repl history and can't recall what
I did.
For me personally, I am learning with each new post so please keep them
coming!
On Wednesday, November 20, 2013 1:26:43 AM UTC, Joshua Ballanco wrote:
In an attempt to be slightly more elegant (whatever that means ;-) ):
-8-8-
(def start [{:key 3 :value 10} {:key 6 :value 30}])
(into [] (map (fn [[k v]] {:key k :value v})
(merge
(into {} (for [x (range 6)] {x nil}))
(into {} (map (juxt :key :value) start)
;;= [{:key 6, :value 30} {:key 0, :value nil} {:key 1, :value nil} {:key
2, :value nil} {:key 3, :value 10} {:key 4, :value nil} {:key 5, :value
nil}]
-8-8-
Cheers,
Josh
On Tuesday, November 19, 2013 at 2:00 PM, Jim - FooBar(); wrote:
On 19/11/13 11:29, Colin Yates wrote:
In Java I would do something like:
// create a convenient look up to avoid nasty N^2 lookups
MapObject, Object keyToValue = new HashMap
for (MapObject, Object kvMap: kvSequence)
keyToValue.put(kvMap.get(key), kvMap.put(value));
ListObject allKeys = calculateAllKeys();
ListMapObject, Object results = new Array
for (Object key: allKeys)
Object result = keyToValue.get(key); // null is fine for missing keys
results.put(key, result);
return results;
this code doesn't do any sorting of keys so I'm not sure it would give
you the exact desired result you posted...
Jim
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
clo...@googlegroups.comjavascript:(mailto:
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: (mailto:
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: (mailto:
clojure+u...@googlegroups.com javascript:).
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)
Hi Sean, First - I hugely appreciate the work you have done and use java.jdbc daily. However, as a complete newbie I found the included DSL very unhelpful. The java.jdbc API is very wide and navigating it was hard, Particularly as it was in a transition from using bound *db* to not, so effectively there seemed two APIs. I started using the DSL and it didn't meet the expectation I think anybody would have for a DSL in that it wasn't complete or expressive enough. There were moments where the combined experience was very very negative and not representative of the quality of the work you have put in. It also made it unclear what the library was supposed to do (regardless of what the documentation says :)). Treating java.jdbc without the DSL and the DSL as separate projects (I realise they are separate namespaces already) would be a much stronger statement of intent I think. To put it another way, at the moment the risk is to interpret java.jdbc as a DSL on top of JDBC with some low level utilities around managing connections. That clearly isn't true and the project comes off looking very poor. Please hear me - I write this only because I think my experience will be very similar to a lot of other people's experiences when they start adopting the library whilst picking up Clojure at the same time! For me, the combination of honeysql and java.jdbc is close to perfect, but my point again is that I came very close many times to throwing java.jdbc out because of the experience of a very wide API which was effectively two APIs and a DSL which didn't meet a reasonable definition of a full 'DSL' (even if the documentation states it is minimal). Moving the DSL into a separate project makes things much simpler. Just my 2 pennies from a very grateful user who wants to avoid other people missing the point. Col On Wednesday, November 20, 2013 3:05:34 AM UTC, Sean Corfield wrote: In response to the (very reasonable) question from Alex Hudek in a recent thread, here are some of my responses to questions that have arisen about the inclusion of the minimal DSLs in the java.jdbc contrib library: Just wondering if the intention is to make the DSL the primary way to work with the API or if clojure.java.jdbc.sql will be completely optional? Completely optional. The idea is just to provide some (optional) sugar for common operations. I have no intention of going particularly deep on the DSL. If folks want a full DSL for SQL in Clojure, I'd suggest https://github.com/jkk/honeysql or http://sqlkorma.com - the former is a DSL to generate SQL that is compatible with clojure.java.jdbc, the latter is a DSL that wraps clojure.java.jdbc. Using the latest release of java.jdbc, does anybody know how I can construct a where clause when I want to check if the value is one of many values? clojure.java.jdbc.sql is a deliberately minimal DSL - Justin Kramer's HoneySQL is what I recommend for more expressive SQL construction (that's the official recommendation based on discussions Justin and I had about java.jdbc and HoneySQL at Clojure/conj 2012). I want to generate sql string using clojure.java.jdbc.sql for eg. SELECT B.ID , B.TITLE ,B.AUTHOR , C.CATEGORY , S.STATUS FROM BOOK B ,CATEGORY C , STATUS S WHERE (B.CATEGORY_ID=C.ID) AND (B.STATUS_ID = B.ID) AND (B.TITLE LIKE %TOM%) How to do this using clojure.java.jdbc.sql dsl functions? The basic DSL cannot do 'like' so you probably want to look at HoneySQL which is the recommended way to extend clojure.java.jdbc. === The justification for the DSL at all is that it provides some sugar for simple, common usage and also provides a template for other more expansive DSLs that the community might write, by showing what the primary API expects in terms of SQL strings and parameter vectors. At World Singles, we use the basic DSL to support a lot of CRUD operations that are doing simple lookups, basic joins, and so on - and we rely on HoneySQL for our reporting queries and anything that is substantially more complex than the basic DSL offers. Will the DSL be expanded to support some additional common SQL operations? Perhaps, based on user feedback - assuming people want something between raw strings and the sophistication of HoneySQL (or any other DSL that the community may produce). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to
Re: core.async timeout channels are values - is this intended
The reason = considers you timeout channels to be equal is that they
are, in fact, the same object. In fact, they may end up being the same
object even with different timeout values:
(identical? (timeout 1) (timeout 2))
;= true
Except I got a false just now with a fresh REPL and same timeout
value... All subsequent invocations return true though, and I'm sure
with a little digging the reason for the false would become clear.
The reason for them being the same object is that timeout goes out of
its way to avoid creating to many timeout channels and will reuse
existing ones if their timeouts are due within a small amount of time
(clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10
ms) of the requested timeout.
Cheers,
Michał
On 20 November 2013 10:08, Thomas G. Kristensen
thomas.g.kristen...@gmail.com wrote:
Hi all,
I ran into a core.async behaviour that confused me a bit the other day. In
some of our systems, we need to fire different timeouts, perform actions and
schedule a new timeout. The problem is, that if the timeouts are of the same
number of ms, we can't distinguish them, and therefore not keep track of and
remove them from a set (at least not easily).
That sounds a bit fuzzy. Hopefully this spike will make it clearer what I'm
trying to say:
(require '[clojure.core.async :refer [chan timeout alts!! alts!]])
(= (chan) (chan))
;; false
(= (timeout 1) (timeout 2))
;; false
(= (timeout 1) (timeout 1))
;; true
(do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
;; only fires 3, the last channel in the map
The intended behaviour of the last loop is to print 1, 2 and 3 (not
necessarily in that order). However, the ch-v map will only contain one
key, as timeouts with the same duration are considered the same value. In
the real example, a new timeout with the same value should be scheduled
again, by being put in the map.
So, my questions are:
- Is this intended behaviour?
- Is there a different pattern for achieving the scheduling behaviour I'm
looking for?
Thanks for your help,
Thomas
--
--
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: core.async timeout channels are values - is this intended
Isn't that not only violating least astonishment, but potentially
introducing a terrible bug into the library? One could use two different
timeout channels in two different alts, and if the timeout channels are
aliased, then perhaps only one of the alts would actually get notified.
On Wed, Nov 20, 2013 at 5:05 AM, Michał Marczyk michal.marc...@gmail.comwrote:
The reason = considers you timeout channels to be equal is that they
are, in fact, the same object. In fact, they may end up being the same
object even with different timeout values:
(identical? (timeout 1) (timeout 2))
;= true
Except I got a false just now with a fresh REPL and same timeout
value... All subsequent invocations return true though, and I'm sure
with a little digging the reason for the false would become clear.
The reason for them being the same object is that timeout goes out of
its way to avoid creating to many timeout channels and will reuse
existing ones if their timeouts are due within a small amount of time
(clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10
ms) of the requested timeout.
Cheers,
Michał
On 20 November 2013 10:08, Thomas G. Kristensen
thomas.g.kristen...@gmail.com wrote:
Hi all,
I ran into a core.async behaviour that confused me a bit the other day.
In
some of our systems, we need to fire different timeouts, perform actions
and
schedule a new timeout. The problem is, that if the timeouts are of the
same
number of ms, we can't distinguish them, and therefore not keep track of
and
remove them from a set (at least not easily).
That sounds a bit fuzzy. Hopefully this spike will make it clearer what
I'm
trying to say:
(require '[clojure.core.async :refer [chan timeout alts!! alts!]])
(= (chan) (chan))
;; false
(= (timeout 1) (timeout 2))
;; false
(= (timeout 1) (timeout 1))
;; true
(do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
;; only fires 3, the last channel in the map
The intended behaviour of the last loop is to print 1, 2 and 3 (not
necessarily in that order). However, the ch-v map will only contain one
key, as timeouts with the same duration are considered the same value. In
the real example, a new timeout with the same value should be scheduled
again, by being put in the map.
So, my questions are:
- Is this intended behaviour?
- Is there a different pattern for achieving the scheduling behaviour I'm
looking for?
Thanks for your help,
Thomas
--
--
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: core.async timeout channels are values - is this intended
The behaviour of timeout channels is to close after the timeout
elapses. This will be visible everywhere the channel is used.
Cheers,
Michał
On 20 November 2013 11:22, Cedric Greevey cgree...@gmail.com wrote:
Isn't that not only violating least astonishment, but potentially
introducing a terrible bug into the library? One could use two different
timeout channels in two different alts, and if the timeout channels are
aliased, then perhaps only one of the alts would actually get notified.
On Wed, Nov 20, 2013 at 5:05 AM, Michał Marczyk michal.marc...@gmail.com
wrote:
The reason = considers you timeout channels to be equal is that they
are, in fact, the same object. In fact, they may end up being the same
object even with different timeout values:
(identical? (timeout 1) (timeout 2))
;= true
Except I got a false just now with a fresh REPL and same timeout
value... All subsequent invocations return true though, and I'm sure
with a little digging the reason for the false would become clear.
The reason for them being the same object is that timeout goes out of
its way to avoid creating to many timeout channels and will reuse
existing ones if their timeouts are due within a small amount of time
(clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10
ms) of the requested timeout.
Cheers,
Michał
On 20 November 2013 10:08, Thomas G. Kristensen
thomas.g.kristen...@gmail.com wrote:
Hi all,
I ran into a core.async behaviour that confused me a bit the other day.
In
some of our systems, we need to fire different timeouts, perform actions
and
schedule a new timeout. The problem is, that if the timeouts are of the
same
number of ms, we can't distinguish them, and therefore not keep track of
and
remove them from a set (at least not easily).
That sounds a bit fuzzy. Hopefully this spike will make it clearer what
I'm
trying to say:
(require '[clojure.core.async :refer [chan timeout alts!! alts!]])
(= (chan) (chan))
;; false
(= (timeout 1) (timeout 2))
;; false
(= (timeout 1) (timeout 1))
;; true
(do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
;; only fires 3, the last channel in the map
The intended behaviour of the last loop is to print 1, 2 and 3 (not
necessarily in that order). However, the ch-v map will only contain one
key, as timeouts with the same duration are considered the same value.
In
the real example, a new timeout with the same value should be scheduled
again, by being put in the map.
So, my questions are:
- Is this intended behaviour?
- Is there a different pattern for achieving the scheduling behaviour
I'm
looking for?
Thanks for your help,
Thomas
--
--
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: core.async timeout channels are values - is this intended
As for scheduling the printlns, this prints out 1, 2, 3 (in some order):
(let [c (chan)]
(doseq [v [1 2 3]]
(take! (async/timeout 1000) (fn [_] (put! c v
(go-loop [v (! c)]
(println v)
(recur (! c
Cheers,
Michał
On 20 November 2013 11:34, Michał Marczyk michal.marc...@gmail.com wrote:
The behaviour of timeout channels is to close after the timeout
elapses. This will be visible everywhere the channel is used.
Cheers,
Michał
On 20 November 2013 11:22, Cedric Greevey cgree...@gmail.com wrote:
Isn't that not only violating least astonishment, but potentially
introducing a terrible bug into the library? One could use two different
timeout channels in two different alts, and if the timeout channels are
aliased, then perhaps only one of the alts would actually get notified.
On Wed, Nov 20, 2013 at 5:05 AM, Michał Marczyk michal.marc...@gmail.com
wrote:
The reason = considers you timeout channels to be equal is that they
are, in fact, the same object. In fact, they may end up being the same
object even with different timeout values:
(identical? (timeout 1) (timeout 2))
;= true
Except I got a false just now with a fresh REPL and same timeout
value... All subsequent invocations return true though, and I'm sure
with a little digging the reason for the false would become clear.
The reason for them being the same object is that timeout goes out of
its way to avoid creating to many timeout channels and will reuse
existing ones if their timeouts are due within a small amount of time
(clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10
ms) of the requested timeout.
Cheers,
Michał
On 20 November 2013 10:08, Thomas G. Kristensen
thomas.g.kristen...@gmail.com wrote:
Hi all,
I ran into a core.async behaviour that confused me a bit the other day.
In
some of our systems, we need to fire different timeouts, perform actions
and
schedule a new timeout. The problem is, that if the timeouts are of the
same
number of ms, we can't distinguish them, and therefore not keep track of
and
remove them from a set (at least not easily).
That sounds a bit fuzzy. Hopefully this spike will make it clearer what
I'm
trying to say:
(require '[clojure.core.async :refer [chan timeout alts!! alts!]])
(= (chan) (chan))
;; false
(= (timeout 1) (timeout 2))
;; false
(= (timeout 1) (timeout 1))
;; true
(do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
;; only fires 3, the last channel in the map
The intended behaviour of the last loop is to print 1, 2 and 3 (not
necessarily in that order). However, the ch-v map will only contain one
key, as timeouts with the same duration are considered the same value.
In
the real example, a new timeout with the same value should be scheduled
again, by being put in the map.
So, my questions are:
- Is this intended behaviour?
- Is there a different pattern for achieving the scheduling behaviour
I'm
looking for?
Thanks for your help,
Thomas
--
--
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
Re: Releasing Caribou today: Open Source Clojure Web Ecosystem
Ryan - I read somewhere that Datomic support is also being talked about. I think that would be great, as the type of time variant queries that are possible with datomic are not easily replicable in a RDBMS. So will really appreciate that support. On Wednesday, November 20, 2013 12:27:37 AM UTC+5:30, David Simmons wrote: Ryan - that is great news. Are we allowed to know what else will be release :-). cheers Dave -- -- 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)
I agree with Colin and had a similar experience. Even if you say it's completely optional, people will first try it because it's already included. I think honeysql is good and also not any harder to use than the included DSL. It's concept is very simple and clear. Actually, your DSL is magical because it's based on macro. For example, I asked about specifying the default name mapping functions before* and it was not the first time. I had to see the source code to understand why it's not possible. I was only the second but I bet you'll keep hearing this kind of questions over and over again. If you keep the jdbc and DSL in the same library, it becomes confusing to users why some things are not possible. And I don't see any problem with separating it into another library. It's just one additional line in project.clj. * https://groups.google.com/forum/#!searchin/clojure/jdbc/clojure/iOBs_VC09FM/8aUF2xzz7scJ On Wednesday, November 20, 2013 6:41:33 PM UTC+9, Colin Yates wrote: Hi Sean, First - I hugely appreciate the work you have done and use java.jdbc daily. However, as a complete newbie I found the included DSL very unhelpful. The java.jdbc API is very wide and navigating it was hard, Particularly as it was in a transition from using bound *db* to not, so effectively there seemed two APIs. I started using the DSL and it didn't meet the expectation I think anybody would have for a DSL in that it wasn't complete or expressive enough. There were moments where the combined experience was very very negative and not representative of the quality of the work you have put in. It also made it unclear what the library was supposed to do (regardless of what the documentation says :)). Treating java.jdbc without the DSL and the DSL as separate projects (I realise they are separate namespaces already) would be a much stronger statement of intent I think. To put it another way, at the moment the risk is to interpret java.jdbc as a DSL on top of JDBC with some low level utilities around managing connections. That clearly isn't true and the project comes off looking very poor. Please hear me - I write this only because I think my experience will be very similar to a lot of other people's experiences when they start adopting the library whilst picking up Clojure at the same time! For me, the combination of honeysql and java.jdbc is close to perfect, but my point again is that I came very close many times to throwing java.jdbc out because of the experience of a very wide API which was effectively two APIs and a DSL which didn't meet a reasonable definition of a full 'DSL' (even if the documentation states it is minimal). Moving the DSL into a separate project makes things much simpler. Just my 2 pennies from a very grateful user who wants to avoid other people missing the point. Col On Wednesday, November 20, 2013 3:05:34 AM UTC, Sean Corfield wrote: In response to the (very reasonable) question from Alex Hudek in a recent thread, here are some of my responses to questions that have arisen about the inclusion of the minimal DSLs in the java.jdbc contrib library: Just wondering if the intention is to make the DSL the primary way to work with the API or if clojure.java.jdbc.sql will be completely optional? Completely optional. The idea is just to provide some (optional) sugar for common operations. I have no intention of going particularly deep on the DSL. If folks want a full DSL for SQL in Clojure, I'd suggest https://github.com/jkk/honeysql or http://sqlkorma.com - the former is a DSL to generate SQL that is compatible with clojure.java.jdbc, the latter is a DSL that wraps clojure.java.jdbc. Using the latest release of java.jdbc, does anybody know how I can construct a where clause when I want to check if the value is one of many values? clojure.java.jdbc.sql is a deliberately minimal DSL - Justin Kramer's HoneySQL is what I recommend for more expressive SQL construction (that's the official recommendation based on discussions Justin and I had about java.jdbc and HoneySQL at Clojure/conj 2012). I want to generate sql string using clojure.java.jdbc.sql for eg. SELECT B.ID , B.TITLE ,B.AUTHOR , C.CATEGORY , S.STATUS FROM BOOK B ,CATEGORY C , STATUS S WHERE (B.CATEGORY_ID=C.ID) AND (B.STATUS_ID = B.ID) AND (B.TITLE LIKE %TOM%) How to do this using clojure.java.jdbc.sql dsl functions? The basic DSL cannot do 'like' so you probably want to look at HoneySQL which is the recommended way to extend clojure.java.jdbc. === The justification for the DSL at all is that it provides some sugar for simple, common usage and also provides a template for other more expansive DSLs that the community might write, by showing what the primary API expects in terms of SQL strings and parameter vectors. At World Singles, we use
Re: [ANN]: clj.jdbc 0.1-beta1 - Alternative implementation of jdbc wrapper for clojure.
Andrey: I am no lawyer, but the following answer on this QA page about the Eclipse Public License suggests that if you take code from an EPL-licensed project (which java.jdbc is), then the project in which you include it must also be licensed under the EPL (whch clj.jdbc is currently not, as far as I can tell): http://www.eclipse.org/legal/eplfaq.php#USEINANOTHER Andy On Tue, Nov 19, 2013 at 11:16 PM, Andrey Antukh andrei.anto...@gmail.comwrote: Hi agai Soan. Repeating now: as I said previously, copyright notice of taken code should to be present. And is my mistake from the start not incluide it, I don't have any problem for it. Now I have added a copyright notice. Yo can explain me that is a current legal problem has my library. I would fix it. We are all human here, and we make mistakes. It would be better to help fix it instead attempts to discredit... Andrey. Sent from my Nexus 4 On Nov 20, 2013 3:51 AM, Sean Corfield seancorfi...@gmail.com wrote: On Tue, Nov 19, 2013 at 2:28 PM, Michael Klishin michael.s.klis...@gmail.com wrote: 2013/11/20 Andrey Antukh n...@niwi.be About license question: if these functions had not copied, but written from scratch, them would be the same functions with minimal differences or none... Sorry but that's a ridiculous argument. You must respect and obey by the license of the project you take code from. Thank you Michael. Any company that uses Andrey's library at this point is immediately in a difficult position from a legal standpoint... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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.
preferred way to dereference a ref: outside or inside dosync?
Hi all, I've been wondering about this lately and I'm not sure which approach to pick as both give the correct results (in my rudimentary tress-test). So as I understand it is generally suggested to have pure, testable functions that oter side-effecting functions rely on. like so for example: (defn credit A low-level crediting function. Nothing to do with refs. [bank acc-id amount] (update-in bank [acc-id :curr-balance] +' amount)) ;;safe math at the lowest level (defn debit A low-level debiting function. Nothing to do with refs. [bank acc-id amount] (update-in bank [acc-id :curr-balance] -' amount)) ;;safe math at the lowest level (defn deposit! Modifies the bank such that an amount is credited to this account-id. Returns the modified bank. [bank acc-id amount] (dosync (alter bank credit acc-id amount))) (defn withdraw! Modifies the bank such that an amount is debited from this account-id. Returns the modified bank. [bank acc-id amount] (dosync (alter bank debit acc-id amount))) Ok everything is fine so far. Even our side-effecting fns return something (per alter) which is good. Later on however one might want to add another layer. for example this: (defn- transfer1 Modifies bank such that an amount is safely tranfered from an account-id 'from' to an account-id 'to'. Returns the modified bank. [bank amount from to] (dosync (alter bank (fn [b] (- b (credit to amount) (debit from amount)) (defn transfer! Entry point for transactions. Accepts a bank to transact on and an arbitrary number of [amount from to] triplets. Uses 'transfer1' per each triplet. Returns the modified bank. [bank amount-from-to] (assert (zero? (rem (count amount-from-to) 3)) Need mulitples of 3 [amount from to]) (dosync (doseq [[amount from to] (partition 3 amount-from-to)] (transfer1 bank amount from to)) *@bank *)) In this last case 'doseq' would return nil from the transaction. My question is this: Is what I'm doing (deref from within the transaction) the right way or perhaps deref after the transaction has commited and exited (outside the 'dosync')? Is there actually a difference? This code is educational and I'd like it to be clean and that I've covered all my basis for potential questions. If anyone can comment that would be great...:) 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.
Re: cider status
I don't normally use test-mode as it happens -- my main library fails to test correctly in test-mode while working when run through lein for reasons that I have never determined. Clean tests feel nicer anyway. I'm hoping ritz updates soon -- name changes have to happen sometimes, and making the fall out as short as possible has to be a good thing! Now to fix my own nrepl dependencies! Colin Yates colin.ya...@gmail.com writes: That's the culprit - I was wondering why nrepl wouldn't disappear! For me, cider has been rock solid with midje-mode, but I am not really exercising it too much. On Tuesday, November 19, 2013 2:56:05 PM UTC, Phillip Lord wrote: I discovered one of the reasons for my issues with stability yesterday. The version of clojure-test-mode on marmalade still depends on nrepl (rather than cider), so, despite my best efforts to remove nrepl.el it was still getting pulled back in. Fun and games! Phil Phillip Lord philli...@newcastle.ac.uk javascript: writes: I have tried it a couple of times and keep reverting back to nrepl. One of the biggest issues is nrepl-ritz which depends on nrepl and not nrepl-client. So switching to cider appears to mean ditching ritz. -- -- 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] Leiningen 2.3.4 released
Thanks so much to Phil, Nelson, Jean Niklas, and the rest of the Leiningen team! On Tue, Nov 19, 2013 at 1:41 PM, Phil Hagelberg p...@hagelb.org wrote: Hello folks. I'm happy to announce the release of Leiningen 2.3.4. This one is primarily a bugfix release; though there are a few minor enhancements. ## 2.3.4 / 2013-11-18 * Suggest `:exclusions` to possibly confusing `:pedantic?` dependencies. (Nelson Morris, Phil Hagelberg) * Optionally look for snapshot templates in `new` task. (Travis Vachon) * Allow task chains to be declared without commas in project.clj. (Jean Niklas L'orange) * Support extra configurability in `:pom-plugins`. (Dominik Dziedzic) * Fix a bug where implicit :aot warning triggered incorrectly. (Jean Niklas L'orange) * Fix a bug where `lein repl connect` ignored port argument. (Toby Crawley) This brings all the functionality of the deprecated lein-pedantic plugin into Leiningen itself. The snapshot template functionality allows template developers to test their changes more easily, and the support for improved task chaining allows us to express higher-order task invocations in project.clj in a properly nested way without resorting to commas, which are a hack to work around shell arguments' lack of structuring. As usual, running `lein upgrade` will pull in the latest stable release, and if you run into any issues you can always run `lein downgrade 2.3.3` to go back to the previous release. Please report any issues on the Leiningen mailing list or the GitHub issue tracker. Thanks to all the contributors and users who helped us get to this release. -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.
Re: preferred way to dereference a ref: outside or inside dosync?
Hi, you would only want to use Refs when you need to update at least two of them with transaction semantics. When you need to read only one of them, you can just deref them any time you want, if you need a consistent snapshot of two refs, you need to read them inside a transaction, i.e. inside dosync. For an example of the difference search for ;; replace with do for errors on http://skamphausen.de/clojure-workshop-sourcetalk2012/prj/workshop.trade/src/workshop/trade/core.clj (if I may be so bold to link to my own humble experiments with the STM). Best, 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.
Re: core.async timeout channels are values - is this intended
Thanks for the response and discussion. Your proposal solves the problem,
but not the general observation: that timeout channels are not usable keys.
A small tweak on your proposal can make a key-safe channel:
(defn unique-timeout
[ms]
(let [c (chan)]
(take! (timeout ms) (fn [_] (close! c)))
c))
(do (loop [ch-v (into {} (for [v [1 2 3]] [(unique-timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
I think the lesson learned is, that the implementation of timeout-channels
favours efficiency over the possibility of storing them in maps or sets,
and removing them from these datastructures in a loop.
Once again, thanks for all the feedback!
Thomas
On Wednesday, November 20, 2013 10:53:45 AM UTC, Michał Marczyk wrote:
As for scheduling the printlns, this prints out 1, 2, 3 (in some order):
(let [c (chan)]
(doseq [v [1 2 3]]
(take! (async/timeout 1000) (fn [_] (put! c v
(go-loop [v (! c)]
(println v)
(recur (! c
Cheers,
Michał
On 20 November 2013 11:34, Michał Marczyk michal@gmail.comjavascript:
wrote:
The behaviour of timeout channels is to close after the timeout
elapses. This will be visible everywhere the channel is used.
Cheers,
Michał
On 20 November 2013 11:22, Cedric Greevey cgre...@gmail.comjavascript:
wrote:
Isn't that not only violating least astonishment, but potentially
introducing a terrible bug into the library? One could use two
different
timeout channels in two different alts, and if the timeout channels are
aliased, then perhaps only one of the alts would actually get notified.
On Wed, Nov 20, 2013 at 5:05 AM, Michał Marczyk
michal@gmail.comjavascript:
wrote:
The reason = considers you timeout channels to be equal is that they
are, in fact, the same object. In fact, they may end up being the same
object even with different timeout values:
(identical? (timeout 1) (timeout 2))
;= true
Except I got a false just now with a fresh REPL and same timeout
value... All subsequent invocations return true though, and I'm sure
with a little digging the reason for the false would become clear.
The reason for them being the same object is that timeout goes out of
its way to avoid creating to many timeout channels and will reuse
existing ones if their timeouts are due within a small amount of time
(clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10
ms) of the requested timeout.
Cheers,
Michał
On 20 November 2013 10:08, Thomas G. Kristensen
thomas.g@gmail.com javascript: wrote:
Hi all,
I ran into a core.async behaviour that confused me a bit the other
day.
In
some of our systems, we need to fire different timeouts, perform
actions
and
schedule a new timeout. The problem is, that if the timeouts are of
the
same
number of ms, we can't distinguish them, and therefore not keep
track of
and
remove them from a set (at least not easily).
That sounds a bit fuzzy. Hopefully this spike will make it clearer
what
I'm
trying to say:
(require '[clojure.core.async :refer [chan timeout alts!! alts!]])
(= (chan) (chan))
;; false
(= (timeout 1) (timeout 2))
;; false
(= (timeout 1) (timeout 1))
;; true
(do (loop [ch-v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
(when-let [chs (keys ch-v)]
(let [[_ ch] (alts!! chs)]
(println (ch-v ch))
(recur (dissoc ch-v ch)
(println done))
;; only fires 3, the last channel in the map
The intended behaviour of the last loop is to print 1, 2 and 3 (not
necessarily in that order). However, the ch-v map will only contain
one
key, as timeouts with the same duration are considered the same
value.
In
the real example, a new timeout with the same value should be
scheduled
again, by being put in the map.
So, my questions are:
- Is this intended behaviour?
- Is there a different pattern for achieving the scheduling
behaviour
I'm
looking for?
Thanks for your help,
Thomas
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient
with
your
first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups
Clojure group.
To unsubscribe from this group and stop
My recap of Clojure/conj 2013
I've posted a writeup of my experience from this year's Clojure/conj and wanted to share with those who couldn't make it: http://loganlinn.com/blog/2013/11/18/clojureconj-2013/ Big thanks to all who helped organize operate the event! -- -- 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: Using xlisp assoc-lists in clojure
Hello, Thanks for the answers and code hints. What a bit surprise me, is the fact that clojure is announced as 'a lisp' and is relativ poor on working with lists. A long time ago I learned that 'lisp' was the agronym for 'ListProcessing'. ;-) As I note, I am a longtime user of newLISP which is compared in list-processing functions a power horse. But I do not want to blame the language at all, otherwise I would not be interested. I still have to find the best way to get the wanted job done with minimal efforts. Regards Hans-Peter -- -- 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: Using xlisp assoc-lists in clojure
'Relatively bad at lists' ? I think the thing that clojure's intentionally bad at is arbitrary nested mutation, so you're forced to be recursive about things and return values (this is how update-in and assoc-in are implemented), but this has nothing to do with data type. Clojure provides simple (maybe not easy or familiar) components for manipulating data, which includes lists. We should understand the core principles and tradeoffs the language makes before making judgments like this. On Wed, Nov 20, 2013 at 12:03 PM, hpw...@googlemail.com wrote: Hello, Thanks for the answers and code hints. What a bit surprise me, is the fact that clojure is announced as 'a lisp' and is relativ poor on working with lists. A long time ago I learned that 'lisp' was the agronym for 'ListProcessing'. ;-) As I note, I am a longtime user of newLISP which is compared in list-processing functions a power horse. But I do not want to blame the language at all, otherwise I would not be interested. I still have to find the best way to get the wanted job done with minimal efforts. Regards Hans-Peter -- -- 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.
What's new and exciting w.r.t. Clojure use in data analytics, and cloud apps that scale out?
Just looking for interesting tidbits on recent spearheads with, or wins for, Clojure in the cloud with the buzzwords du jour. Part of an interest to take the pulse of Clojure in the domains for which my employer presently uses other tools. I like Java just fine (for what it is), and I have a lot of hope for Clojure to rectify some of the things that Java isn't. Some of these modern languages like Coffeescript, Groovy, or Python almost make the limitations of Fortran syntax look good. (Yes, my indentation of one language statement was off by 2 spaces today and my program didn't work, I confess irritation as a source of motivation to learn new things). What's new and exciting!? My personal interest is directed at large AWS cloud apps where clojure might be bringing the logic to data or the data to logic in an interesting fashion, and the ever present need for portals on the results of those processes. Thanks for any pointers! Dave -- -- 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?
Jim, The value for all refs whose value you don't actually modify inside a transaction should be obtained through ensurehttp://clojuredocs.org/clojure_core/clojure.core/ensure if you want to make sure :P their value won't be changed by a different transaction, that way you get a consistent value when the current transaction is finally committed. In the example you show, this is not a problem since all transactions change the value of all the refs they read, but it's something to take into account if you have a bunch of transactions doing different things and only reading from some of the refs. J On Wednesday, November 20, 2013 5:17:38 AM UTC-10, Stefan Kamphausen wrote: Hi, you would only want to use Refs when you need to update at least two of them with transaction semantics. When you need to read only one of them, you can just deref them any time you want, if you need a consistent snapshot of two refs, you need to read them inside a transaction, i.e. inside dosync. For an example of the difference search for ;; replace with do for errors on http://skamphausen.de/clojure-workshop-sourcetalk2012/prj/workshop.trade/src/workshop/trade/core.clj(if I may be so bold to link to my own humble experiments with the STM). Best, 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.
Re: What's new and exciting w.r.t. Clojure use in data analytics, and cloud apps that scale out?
Hi Dave, I'm probably biased because it's my project, but I think core.matrix has the potential to make data analytics applications in Clojure extremely compelling. https://github.com/mikera/core.matrix It brings multi-dimensional array programming capabilities to Clojure (philosophically along the lines of APL, but with a much more modern, functional style that fits with Clojure idioms). core.matrix was designed to target exactly the kind of cloud based, data-driven applications that you seem to be interested in. Hopefully there will be a video of my talk about core.matrix at the Clojure Conj coming out soon. On Wednesday, 20 November 2013 11:30:08 UTC-8, Dave Tenny wrote: Just looking for interesting tidbits on recent spearheads with, or wins for, Clojure in the cloud with the buzzwords du jour. Part of an interest to take the pulse of Clojure in the domains for which my employer presently uses other tools. I like Java just fine (for what it is), and I have a lot of hope for Clojure to rectify some of the things that Java isn't. Some of these modern languages like Coffeescript, Groovy, or Python almost make the limitations of Fortran syntax look good. (Yes, my indentation of one language statement was off by 2 spaces today and my program didn't work, I confess irritation as a source of motivation to learn new things). What's new and exciting!? My personal interest is directed at large AWS cloud apps where clojure might be bringing the logic to data or the data to logic in an interesting fashion, and the ever present need for portals on the results of those processes. Thanks for any pointers! Dave -- -- 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)
Thanks for the explanation Sean. That was helpful. Alex On Tuesday, November 19, 2013 10:05:34 PM UTC-5, Sean Corfield wrote: In response to the (very reasonable) question from Alex Hudek in a recent thread, here are some of my responses to questions that have arisen about the inclusion of the minimal DSLs in the java.jdbc contrib library: Just wondering if the intention is to make the DSL the primary way to work with the API or if clojure.java.jdbc.sql will be completely optional? Completely optional. The idea is just to provide some (optional) sugar for common operations. I have no intention of going particularly deep on the DSL. If folks want a full DSL for SQL in Clojure, I'd suggest https://github.com/jkk/honeysql or http://sqlkorma.com - the former is a DSL to generate SQL that is compatible with clojure.java.jdbc, the latter is a DSL that wraps clojure.java.jdbc. Using the latest release of java.jdbc, does anybody know how I can construct a where clause when I want to check if the value is one of many values? clojure.java.jdbc.sql is a deliberately minimal DSL - Justin Kramer's HoneySQL is what I recommend for more expressive SQL construction (that's the official recommendation based on discussions Justin and I had about java.jdbc and HoneySQL at Clojure/conj 2012). I want to generate sql string using clojure.java.jdbc.sql for eg. SELECT B.ID , B.TITLE ,B.AUTHOR , C.CATEGORY , S.STATUS FROM BOOK B ,CATEGORY C , STATUS S WHERE (B.CATEGORY_ID=C.ID) AND (B.STATUS_ID = B.ID) AND (B.TITLE LIKE %TOM%) How to do this using clojure.java.jdbc.sql dsl functions? The basic DSL cannot do 'like' so you probably want to look at HoneySQL which is the recommended way to extend clojure.java.jdbc. === The justification for the DSL at all is that it provides some sugar for simple, common usage and also provides a template for other more expansive DSLs that the community might write, by showing what the primary API expects in terms of SQL strings and parameter vectors. At World Singles, we use the basic DSL to support a lot of CRUD operations that are doing simple lookups, basic joins, and so on - and we rely on HoneySQL for our reporting queries and anything that is substantially more complex than the basic DSL offers. Will the DSL be expanded to support some additional common SQL operations? Perhaps, based on user feedback - assuming people want something between raw strings and the sophistication of HoneySQL (or any other DSL that the community may produce). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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] clojure-sql 0.1.0: relational algebra in clojure
Hi Carlo - I'm using the 2.0 snapshot. How should I express a join on multiple columns, ie SELECT blah FROM t1 JOIN t2 ON (t1.a=t2.b) AND (t1.c=t2.d) ? On Wednesday, July 3, 2013 1:48:07 AM UTC-7, Carlo wrote: Hey guys! I've been working on a small library to make writing SQL queries a little bit easier. It's along the same lines as ClojureQL, but takes a different approach and compiles into quite different SQL in the end. At the moment it's quite immature, but it should be able to support any queries which can be expressed in relational algebra. There will be some SQL queries which can't be expressed in clojure-sql, but hopefully there won't be too many of those. A greater limitation is that at the moment the SQL generation is specific to the PostgresSQL database (although any contributions for other databases are welcome!). Dependency vector: [clojure-sql 0.1.0] Repository: https://bitbucket.org/czan/clojure-sql Clojars link: https://clojars.org/clojure-sql Let me know what you think! Carlo -- -- 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.logic merge substitutions map?
Thanks for the advice and code-snippet. On Monday, November 18, 2013 7:43:12 PM UTC-8, Norman Richards wrote: On Mon, Nov 18, 2013 at 6:26 PM, Kevin Downey red...@gmail.comjavascript: wrote: https://github.com/sonian/Greenmail/blob/master/src/clj/greenmail/db.clj#L98-L126 has an example, using clojure.core.logic/all to make a goal which is a conjunction of the clojure.core.logic/== goals Based on my experience writing pldb, using == in this situation is going to work better than using unify as shown in the code sample base on the video. I found that using unify for this type of custom relation appears to work but will not do the right thing with more complicated situations. I found constraints particularly problematic. Switching from unify to == makes sure everything you want to happen on unify actually happens. -- -- 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]: clj.jdbc 0.1-beta1 - Alternative implementation of jdbc wrapper for clojure.
Hi Andy. A lot of thanks for this information. I was also researching on this point. Currently I have removed all taken code from the clojure.java.jdbc, license problem should be solved. Again, I in no way want to belittle the original work. It was big mistake on my part not to mention from start of the project. Andrey 2013/11/20 Andy Fingerhut andy.finger...@gmail.com Andrey: I am no lawyer, but the following answer on this QA page about the Eclipse Public License suggests that if you take code from an EPL-licensed project (which java.jdbc is), then the project in which you include it must also be licensed under the EPL (whch clj.jdbc is currently not, as far as I can tell): http://www.eclipse.org/legal/eplfaq.php#USEINANOTHER Andy On Tue, Nov 19, 2013 at 11:16 PM, Andrey Antukh andrei.anto...@gmail.comwrote: Hi agai Soan. Repeating now: as I said previously, copyright notice of taken code should to be present. And is my mistake from the start not incluide it, I don't have any problem for it. Now I have added a copyright notice. Yo can explain me that is a current legal problem has my library. I would fix it. We are all human here, and we make mistakes. It would be better to help fix it instead attempts to discredit... Andrey. Sent from my Nexus 4 On Nov 20, 2013 3:51 AM, Sean Corfield seancorfi...@gmail.com wrote: On Tue, Nov 19, 2013 at 2:28 PM, Michael Klishin michael.s.klis...@gmail.com wrote: 2013/11/20 Andrey Antukh n...@niwi.be About license question: if these functions had not copied, but written from scratch, them would be the same functions with minimal differences or none... Sorry but that's a ridiculous argument. You must respect and obey by the license of the project you take code from. Thank you Michael. Any company that uses Andrey's library at this point is immediately in a difficult position from a legal standpoint... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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. -- Andrey Antukh - Андрей Антух - n...@niwi.be http://www.niwi.be/about.html http://www.kaleidos.net/A5694F/ Linux is for people who hate Windows, BSD is for people who love UNIX Social Engineer - Because there is no patch for human stupidity -- -- 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
Re: java.jdbc DSLs (java.jdbc.sql / java.jdbc.ddl)
Thank you both - that's excellent feedback! I certainly don't want the library to cause confusion so maybe hiding/removing the DSLs would be the best path going forward. Right now, a handful of the DSL functions are used to generate the SQL behind delete!, insert! and update! as well as the core implementation of the naming strategy stuff. We're also using a few of them in production code at World Singles but it would be easy enough to back off that and switch to HoneySQL (which we use extensively elsewhere). I totally agree about the API being too broad. I'd like to just drop the old API completely but experience with APIs changing in contrib libraries has shown that backward compatibility needs to be maintained for at least a version or two so folks can migrate off the old API. I was planning to streamline the API - dropping the old API that relied on the dynamic *db* variable - in 0.5.0 but maybe I'll make that the focus of 0.4.0 instead. The feedback on the DSLs - ever since my first proposal to add them - seems to be overwhelmingly negative so at this point I'm now considering removing them from 0.3.0 rather than perpetuate the confusion. Is anyone using the java.jdbc.sql namespace? (besides World Singles :) Sean On Wed, Nov 20, 2013 at 3:52 AM, Alice dofflt...@gmail.com wrote: I agree with Colin and had a similar experience. Even if you say it's completely optional, people will first try it because it's already included. I think honeysql is good and also not any harder to use than the included DSL. It's concept is very simple and clear. Actually, your DSL is magical because it's based on macro. For example, I asked about specifying the default name mapping functions before* and it was not the first time. I had to see the source code to understand why it's not possible. I was only the second but I bet you'll keep hearing this kind of questions over and over again. If you keep the jdbc and DSL in the same library, it becomes confusing to users why some things are not possible. And I don't see any problem with separating it into another library. It's just one additional line in project.clj. * https://groups.google.com/forum/#!searchin/clojure/jdbc/clojure/iOBs_VC09FM/8aUF2xzz7scJ On Wednesday, November 20, 2013 6:41:33 PM UTC+9, Colin Yates wrote: Hi Sean, First - I hugely appreciate the work you have done and use java.jdbc daily. However, as a complete newbie I found the included DSL very unhelpful. The java.jdbc API is very wide and navigating it was hard, Particularly as it was in a transition from using bound *db* to not, so effectively there seemed two APIs. I started using the DSL and it didn't meet the expectation I think anybody would have for a DSL in that it wasn't complete or expressive enough. There were moments where the combined experience was very very negative and not representative of the quality of the work you have put in. It also made it unclear what the library was supposed to do (regardless of what the documentation says :)). Treating java.jdbc without the DSL and the DSL as separate projects (I realise they are separate namespaces already) would be a much stronger statement of intent I think. To put it another way, at the moment the risk is to interpret java.jdbc as a DSL on top of JDBC with some low level utilities around managing connections. That clearly isn't true and the project comes off looking very poor. Please hear me - I write this only because I think my experience will be very similar to a lot of other people's experiences when they start adopting the library whilst picking up Clojure at the same time! For me, the combination of honeysql and java.jdbc is close to perfect, but my point again is that I came very close many times to throwing java.jdbc out because of the experience of a very wide API which was effectively two APIs and a DSL which didn't meet a reasonable definition of a full 'DSL' (even if the documentation states it is minimal). Moving the DSL into a separate project makes things much simpler. Just my 2 pennies from a very grateful user who wants to avoid other people missing the point. Col On Wednesday, November 20, 2013 3:05:34 AM UTC, Sean Corfield wrote: In response to the (very reasonable) question from Alex Hudek in a recent thread, here are some of my responses to questions that have arisen about the inclusion of the minimal DSLs in the java.jdbc contrib library: Just wondering if the intention is to make the DSL the primary way to work with the API or if clojure.java.jdbc.sql will be completely optional? Completely optional. The idea is just to provide some (optional) sugar for common operations. I have no intention of going particularly deep on the DSL. If folks want a full DSL for SQL in Clojure, I'd suggest https://github.com/jkk/honeysql or http://sqlkorma.com - the former is a DSL to generate SQL that is compatible with clojure.java.jdbc, the
Re: java.jdbc DSLs (java.jdbc.sql / java.jdbc.ddl)
On 20 November 2013 22:25, Sean Corfield seancorfi...@gmail.com wrote: Is anyone using the java.jdbc.sql namespace? (besides World Singles :) Only the 'where' function, in a few places. Ray. -- -- 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.
a Prensentation I made to a Tunisian University to Clojure... too bad it is in French !
Hey Guys, I wanted to share these with the community, too bad it is in french, but it is the language used for scientific education in Tunisia ! Hope it'll help, http://www.clojure.tn/2013/11/20/Slides-Seminaire-FST.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.
Next ClojureScript Release: 1 more ticket
If you are using ClojureScript source maps please try master and give us feedback, the experience should be significantly improved and we now have clear errors when the wrong combination of compiler options are used. You can install a local copy of master by checking out the repo and running ./script/build from the repo directory. The only thing holding back this next release is we need someonee on Windows to take a look at: http://dev.clojure.org/jira/browse/CLJS-681 Thanks! David -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: Next ClojureScript Release: 1 more ticket
And by take a look, I mean confirm that the issue no longer exists in master. David On Wed, Nov 20, 2013 at 6:12 PM, David Nolen dnolen.li...@gmail.com wrote: If you are using ClojureScript source maps please try master and give us feedback, the experience should be significantly improved and we now have clear errors when the wrong combination of compiler options are used. You can install a local copy of master by checking out the repo and running ./script/build from the repo directory. The only thing holding back this next release is we need someonee on Windows to take a look at: http://dev.clojure.org/jira/browse/CLJS-681 Thanks! David -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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] Leiningen 2.3.4 released
Thanks guys for the hard work On Wednesday, November 20, 2013 4:30:03 PM UTC+2, Tim Visher wrote: Thanks so much to Phil, Nelson, Jean Niklas, and the rest of the Leiningen team! On Tue, Nov 19, 2013 at 1:41 PM, Phil Hagelberg ph...@hagelb.orgjavascript: wrote: Hello folks. I'm happy to announce the release of Leiningen 2.3.4. This one is primarily a bugfix release; though there are a few minor enhancements. ## 2.3.4 / 2013-11-18 * Suggest `:exclusions` to possibly confusing `:pedantic?` dependencies. (Nelson Morris, Phil Hagelberg) * Optionally look for snapshot templates in `new` task. (Travis Vachon) * Allow task chains to be declared without commas in project.clj. (Jean Niklas L'orange) * Support extra configurability in `:pom-plugins`. (Dominik Dziedzic) * Fix a bug where implicit :aot warning triggered incorrectly. (Jean Niklas L'orange) * Fix a bug where `lein repl connect` ignored port argument. (Toby Crawley) This brings all the functionality of the deprecated lein-pedantic plugin into Leiningen itself. The snapshot template functionality allows template developers to test their changes more easily, and the support for improved task chaining allows us to express higher-order task invocations in project.clj in a properly nested way without resorting to commas, which are a hack to work around shell arguments' lack of structuring. As usual, running `lein upgrade` will pull in the latest stable release, and if you run into any issues you can always run `lein downgrade 2.3.3` to go back to the previous release. Please report any issues on the Leiningen mailing list or the GitHub issue tracker. Thanks to all the contributors and users who helped us get to this release. -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.
ANN: Clojure High Performance Programming
Hi, I am pleased to announce availability of the book `Clojure High Performance Programming` that I have been writing for the better part of this year: http://www.packtpub.com/clojure-high-performance-programming/book This book is ideally meant for intermediate Clojure programmers. It is divided into seven chapters covering Clojure abstractions, Java interop, JVM internals, Concurrency and other performance-related topics. Shantanu -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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.
[ANN] Major update of modern-cljs
Hi all, I just updated all the modern-cljs tutorials to the latest available libs and plugins. it has been a true PITA, because in few weeks a lot of libs/plugins used in the modern-cljs series of tutorials on ClojureScript have been considerably updated (and I had to update all the branches, one for each of the current 22 tutorials). It took me a full day to be able to make the updates (hopefully without too many errors) and there is no a more boring work that this (the only competitor being unit testing). Here is the link https://github.com/magomimmo/modern-cljs.git I'm exhaust. HIH By best Mimmo signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [ANN] optparse-clj: Functional GNU-style command line options parsing
On Sun 25 Aug 2013 at 09:05:15PM -0500, gaz jones wrote: Hey, i am the current maintainer of tools.cli - i have very little time to make any changes to it at the moment (kids :) ). I'm not sure what the process is for adding you as a developer or transferring ownership etc but if I'm happy to do so as I have no further plans for working on it. Hello Paul, Gareth, and everyone else interested in tools.cli, I finally noticed that my Clojure CA acceptance was noted on http://clojure.org/contributing, so I have submitted my proposal on JIRA: http://dev.clojure.org/jira/browse/TCLI-6 The formatting is a bit ugly, so here is a plain text version: https://gist.github.com/guns/7573819/raw/26fc5a741d78b9cf1753fcde1a071dd467d44b4f/tools.cli.proposal.mail Comments are appreciated. If this is acceptable to all, then I will happily begin work on it ASAP. Cheers, guns pgpWntqn55ldL.pgp Description: PGP signature
Re: [ANN] optparse-clj: Functional GNU-style command line options parsing
On Wed 20 Nov 2013 at 06:32:49PM -0600, guns wrote: The formatting is a bit ugly, so here is a plain text version: https://gist.github.com/guns/7573819/raw/26fc5a741d78b9cf1753fcde1a071dd467d44b4f/tools.cli.proposal.mail Sorry for the double post. The url above should be: https://gist.github.com/guns/7573819/raw The first one posted contains an error. guns pgphmd5ugC3vj.pgp Description: PGP signature
Re: [Job spam] Write Clojure in your pajamas, for decent money in a pleasant company, remote pairing all the time
On Wednesday, 20 November 2013 01:16:35 UTC-7, Alex Baranosky wrote: Why all that pesky Ruby? =D 1. Because it was a new/shiny object 8 years ago 2. It actually worked better than Bash, Tcl, Perl, Java or even Python for me in a testing team toolsmith role in mid 2000s 3. In 2006-7 ThoughtWiorks had quite a bit of commercial success selling Ruby work. Stuff needed to be done to make sure we can deliver Something along those lines. Actually, with Clojure, I'm still at the stage of I figured out how to flatten this bunch of sequences, and it makes me feel smart, but why the hell was it difficult at all? It doesn't feel like jumping through burning hoops the way learning Haskell does, but still... With Ruby, I had no such issues, ever. Much smaller paradigm shift, I guess. --Alex -- -- 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: [Job spam] Write Clojure in your pajamas, for decent money in a pleasant company, remote pairing all the time
On Tuesday, November 19, 2013 7:44:33 PM UTC-5, Alexey Verkhovsky wrote:
Back to the original subject of the thread, it looks like either there is
more Clojure work than people with platform expertise, or Clojure is a
mostly South American phenomenon. One way or the other, South America is
the only place I've got any responses from so far. {puzzled}
We are only hiring master programmers and very strong journeymen.
My guess is master programmers in the US already have plenty of
opportunities to thrive at exciting places and are probably already
established in excellent companies, whereas as in other countries it might
be harder to find such excellent work conditions and the opportunity to
work remotely for your company makes it extra attractive.
--
--
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: Clojure High Performance Programming
Now also available on Amazon US: http://www.amazon.com/dp/1782165606/?tag=packtpubli-20 Amazon UK: http://www.amazon.co.uk/dp/1782165606/?tag=packtpubli-21 Shantanu On Thursday, 21 November 2013 05:21:45 UTC+5:30, Shantanu Kumar wrote: Hi, I am pleased to announce availability of the book `Clojure High Performance Programming` that I have been writing for the better part of this year: http://www.packtpub.com/clojure-high-performance-programming/book This book is ideally meant for intermediate Clojure programmers. It is divided into seven chapters covering Clojure abstractions, Java interop, JVM internals, Concurrency and other performance-related topics. Shantanu -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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 2 years of ClojureWerkz
Huge fan of ClojureWerkz libraries. Thanks for the great code and documentation! On Wednesday, November 20, 2013 4:26:23 PM UTC+8, Las wrote: Hi Michael, outstanding work, thanks for taking the lead on this effort and many thanks to all the contributors. Las Sent from my phone On Nov 20, 2013 12:13 AM, Bruce Durling b...@otfrom.com javascript: wrote: Michael, Congrats and keep on going. I love using your libraries. cheers, Bruce On Tue, Nov 19, 2013 at 11:05 PM, Michael Klishin michael@gmail.com javascript: wrote: A couple of weeks ago ClojureWerkz [1] turned two years old. We are at 29 projects (not including failed experiments) and kicking. There have been dozens of contributors, entire major releases brilliantly managed by people outside of our tiny core team, and a pretty high bar in project quality sustained [2] [3]. I think it's fair to say that there have been positive changes in the overall Clojure library ecosystem, hopefully in part due to how vocal we've been (102 blog posts on blog.clojurewerkz.org this year alone). These days many world famous institutions and companies we respect use various ClojureWerkz projects to power their products and internal tools. Needless to say, we did not plan for it in 2011. So thank you, both users and contributors. There are some new projects in the pipeline and our values do not change: documentation, sane release practices, ease of contributing and backwards compatibility. We love all that boring stuff. Here's to another few years! 1. http://clojurewerkz.org 2. http://blog.clojurewerkz.org/blog/2013/04/20/how-to-make-your-open-source-project-really-awesome/ 3. http://www.slideshare.net/michaelklishin/open-source-responsibly -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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/groups/opt_out. -- @otfrom | CTO co-founder @MastodonC | mastodonc.com See recent coverage of us in the Economist http://econ.st/WeTd2i and the Financial Times http://on.ft.com/T154BA -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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/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.
[ANN] Component: dependency injection and state management
This is a small library/framework I've been working on for a few months. https://github.com/stuartsierra/component I use this to manage runtime state in combination with my reloaded workflow using tools.namespace.[1] I've started using this on some personal and professional projects and it seems to be working fairly well. [1]: http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded -- -- 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: Clojure High Performance Programming
Congratulation on the book Shantanu! On Wed, Nov 20, 2013 at 5:16 PM, Shantanu Kumar kumar.shant...@gmail.comwrote: Now also available on Amazon US: http://www.amazon.com/dp/1782165606/?tag=packtpubli-20 Amazon UK: http://www.amazon.co.uk/dp/1782165606/?tag=packtpubli-21 Shantanu On Thursday, 21 November 2013 05:21:45 UTC+5:30, Shantanu Kumar wrote: Hi, I am pleased to announce availability of the book `Clojure High Performance Programming` that I have been writing for the better part of this year: http://www.packtpub.com/clojure-high-performance-programming/book This book is ideally meant for intermediate Clojure programmers. It is divided into seven chapters covering Clojure abstractions, Java interop, JVM internals, Concurrency and other performance-related topics. Shantanu -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: [ClojureScript] Re: Next ClojureScript Release: 1 more ticket
It still isn't working on Windows. At https://github.com/clojure/clojurescript/blob/047dbb3d2bd7c3a2e00805ec2f2480e449451521/src/clj/cljs/closure.clj#L750 path is either a file:// url or something like: /C:/Temp/cstest2/out/cljs/core.js - which is a bit mangled, and is caused by calling .getPath on a file URL. But (keys (::comp/compiled-cljs @env/*compiler*)) are absolute File paths with backslashes, eg C:\Temp\cstest2\out\cljs\core.js I think calling .getPath on a file:// URL or URI might be questionable unless you are going to carefully relativize it before you do anything with it. Also note that the changes on master use java.io.File.toPath() which requires Java 7. We should probably check that everything works with paths with spaces in too. Whatever process converts files to urls needs to know to apply url escaping. -- -- 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: Next ClojureScript Release: 1 more ticket
OK this is definitely a case where a patch from Windows users is most
welcome. I'm willing to stall a release if someone will step forward.
Thanks!
David
On Wednesday, November 20, 2013, David Powell wrote:
It still isn't working on Windows.
At
https://github.com/clojure/clojurescript/blob/047dbb3d2bd7c3a2e00805ec2f2480e449451521/src/clj/cljs/closure.clj#L750
path is either a file:// url or something
like: /C:/Temp/cstest2/out/cljs/core.js - which is a bit mangled, and is
caused by calling .getPath on a file URL.
But (keys (::comp/compiled-cljs @env/*compiler*)) are absolute File paths
with backslashes, eg C:\Temp\cstest2\out\cljs\core.js
I think calling .getPath on a file:// URL or URI might be questionable
unless you are going to carefully relativize it before you do anything with
it.
Also note that the changes on master use java.io.File.toPath() which
requires Java 7.
We should probably check that everything works with paths with spaces in
too. Whatever process converts files to urls needs to know to apply url
escaping.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
clojure@googlegroups.comjavascript:_e({}, 'cvml',
'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 javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@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 javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@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: My recap of Clojure/conj 2013
Thanks for this Logan. :) -- -- 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: [ClojureScript] Re: Next ClojureScript Release: 1 more ticket
I think a good approach might be to: Keep everything as file:// urls given that we need to use urls anyway for.jar references. Never call .getPath on a URI / URL - it undoes the URL escaping that we want, and it returns weird /c:/ things on Windows that don't work as anything. Write our own URL relativizer that works on file url's and can cope with urls where result starts with ../ rather than falling back to an absolute url as Java's methods do. -- -- 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] optparse-clj: Functional GNU-style command line options parsing
Hey guns, Yeah sounds good, I don't have admin access to add you as a developer so will ask on the clojure-dev mailing list to see who can do it and cc you on that. Cheers, Gaz On Wed, Nov 20, 2013 at 6:40 PM, guns s...@sungpae.com wrote: On Wed 20 Nov 2013 at 06:32:49PM -0600, guns wrote: The formatting is a bit ugly, so here is a plain text version: https://gist.github.com/guns/7573819/raw/26fc5a741d78b9cf1753fcde1a071dd467d44b4f/tools.cli.proposal.mail Sorry for the double post. The url above should be: https://gist.github.com/guns/7573819/raw The first one posted contains an error. guns -- -- 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.
[ANN] tools.reader 0.8.0 released
https://github.com/clojure/tools.reader
Changelog:
https://github.com/clojure/tools.reader/blob/master/CHANGELOG.md
Leiningen dependency information: [org.clojure/tools.reader 0.8.0]
While the releases I made on the last months contained mainly small
bugfixes and enhancements needed specifically for better integration in
clojurescript, this one contains a more interesting enhancement.
Thanks to the awesome work by Alex Redington, tools.reader now provides
richer informations regarding the forms it is reading in the form of
attached metadata; specifically it now adds end-line/end-column metadata
information as opposed to only line/column info and can optionally
keep source information.
To see it in action:
clojure.tools.reader (meta (read (source-logging-push-back-reader [^:foo
bar])))
{:end-column 12, :end-line 1, :column 1, :line 1, :source [^:foo bar]}
clojure.tools.reader (meta (first (read (source-logging-push-back-reader
[^:foo bar]
{:foo true, :end-column 11, :end-line 1, :column 8, :line 1, :source ^:foo
bar}
Nicola
--
--
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] clojure-sql 0.1.0: relational algebra in clojure
Hi Mark! On Wed, Nov 20, 2013 at 01:11:11PM -0800, Mark wrote: I'm using the 2.0 snapshot. How should I express a join on multiple columns, ie SELECT blah FROM t1 JOIN t2 ON (t1.a=t2.b) AND (t1.c=t2.d) ? Something like this should work: (let [t1 (- (table :t1) (project [:a :c])) t2 (- (table :t2) (project [:b :d]))] (join t1 t2 :on `(and (= :a :b) (= :c :d If you've got shared attributes this won't work for you, though, because then there's an ambiguity about whether to use a natural join (ie. joining on equality of shared attributes) or your join condition (which will leave an ambiguity about which shared attribute to use). In that case you can use something like this: (let [t1 (- (table :t1) (project [:a :b])) t2 (- (table :t2) (project [:a :c]))] (join (rename t1 (as-subobject :t1)) (rename t2 (as-subobject :t2)) :on `(and (= :t1.a :t2.c) (= :t2.a :t1.b Sorry about the lack of documentation for this. I'm working on it, but I've been quite busy/distracted lately. Hopefully I'll have some more time to get back to it soon. Carlo -- -- 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: Next ClojureScript Release: 1 more ticket
While talk is great a patch is better. If no one commits to a patch we
will release and take a patch when we get it. Accounting for platforms is a
lot of work and in the future it's only going to get more complicated.
Community support is critical here.
On Wednesday, November 20, 2013, David Powell wrote:
I think a good approach might be to:
Keep everything as file:// urls given that we need to use urls anyway
for.jar references.
Never call .getPath on a URI / URL - it undoes the URL escaping that we
want, and it returns weird /c:/ things on Windows that don't work as
anything.
Write our own URL relativizer that works on file url's and can cope with
urls where result starts with ../ rather than falling back to an absolute
url as Java's methods do.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
clojure@googlegroups.comjavascript:_e({}, 'cvml',
'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 javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@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 javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@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: My recap of Clojure/conj 2013
Please accept my thanks as well! Regards, Praki Prakash On Wed, Nov 20, 2013 at 6:25 PM, Eduardo Lávaque eduanlava...@gmail.comwrote: Thanks for this Logan. :) -- -- 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: [ANN] clojure-sql 0.1.0: relational algebra in clojure
Thanks, Carlo. Even without the documentation, I'm beginning to get the hang of the DSL. I should have guessed that '(and...) would have done the trick. I'd like to put a request in for using a map or a vector of pairs as an alternative since it's easier to construct those. One more request: Support for SELECT DISTINCT. Using 0.1.0, I could get around the lack of DISTINCT by using GROUP BY but with the new projection argument, that becomes inconvenvient. In our project, we do a ton of programmatic SQL manipulation and your library makes it much easier. Thanks for contribution! On Wednesday, November 20, 2013 7:54:19 PM UTC-8, Carlo wrote: Hi Mark! On Wed, Nov 20, 2013 at 01:11:11PM -0800, Mark wrote: I'm using the 2.0 snapshot. How should I express a join on multiple columns, ie SELECT blah FROM t1 JOIN t2 ON (t1.a=t2.b) AND (t1.c=t2.d) ? Something like this should work: (let [t1 (- (table :t1) (project [:a :c])) t2 (- (table :t2) (project [:b :d]))] (join t1 t2 :on `(and (= :a :b) (= :c :d If you've got shared attributes this won't work for you, though, because then there's an ambiguity about whether to use a natural join (ie. joining on equality of shared attributes) or your join condition (which will leave an ambiguity about which shared attribute to use). In that case you can use something like this: (let [t1 (- (table :t1) (project [:a :b])) t2 (- (table :t2) (project [:a :c]))] (join (rename t1 (as-subobject :t1)) (rename t2 (as-subobject :t2)) :on `(and (= :t1.a :t2.c) (= :t2.a :t1.b Sorry about the lack of documentation for this. I'm working on it, but I've been quite busy/distracted lately. Hopefully I'll have some more time to get back to it soon. Carlo -- -- 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.
Compiling ClojureScript in the repl using a macro defined in Clojure
Hello, I'm stuck on this particular problem that I'm having problem figuring out what to do: Say I have a leiningen project that has a simple ClojureScript src/cljs/hello_world/hello.cljs file that has the following: (ns hello-world.hello (:require-macros [hello-world.macro :as macro])) (defn ^:export main [] (macro/my-when true (.write js/document Hello, world!))) and I have the macro file macro.clj (ns hello-world.macro) (defmacro my-when [condition body] `(if ~condition (do ~@body))) I can't figure out where do I put macro.clj for cljsc or cljs.closure/build to find the macro. I tried placing the macro.clj in the same directory as hello.cljs or place it under src/clj/hello_world or place it directory under src/hello_world. It doesn't matter where I put it, it will not compile as I get the following error: FileNotFoundException Could not locate hello_world/macro__init.class or hello_world/macro.clj on classpath: clojure.lang.RT.load (RT.java:443) Thank you -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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] Major update of modern-cljs
Hi Mimmo, Mimmo Cosenza mimmo.cose...@gmail.com writes: it has been a true PITA, because in few weeks a lot of libs/plugins used in the modern-cljs series of tutorials on ClojureScript have been considerably updated (and I had to update all the branches, one for each of the current 22 tutorials). I know it won't be a huge relief, but I must say those tutorials are *really* a big help! So *thanks* a lot for the bug PITA work :) -- Bastien -- -- 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.
