Re: type hinting overloaded methods
Phillip Lord phillip.l...@newcastle.ac.uk writes: Mikera mike.r.anderson...@gmail.com writes: On Wednesday, 11 December 2013 14:50:36 UTC, Phillip Lord wrote: Macros that generate type hints can get pretty ugly. Yes, I notice that! I ran into the same problem with vectorz-clj The following pattern ended up working for me: the trick to to create a local symbol that you can tag (defmacro tag-symbol [tag form] (let [tagged-sym (vary-meta (gensym res) assoc :tag tag)] `(let [~tagged-sym ~form] ~tagged-sym))) Will try, thanks for the pointer! That is the strangest macro ever. It expands to something like (let [x y] x) yet still actually does something useful. My end solution looks like this: (defmacro with-types [spec body] Given a spec of the form [symbol [types]] evaluate body if and only the value of symbol is an instance? of one of types. The symbol is type-hinted to the type of the first of types to match. The main aim for this is to avoid reflective calls to overloaded methods in Java. So if we have an overloaded static method call: C.met(String) C.met(Double) C.met(Boolean) (with-types [val [String Double Boolean]] (C/met val) will call met without reflection, so long as val is one of String, Double or Boolean. If none of the types are matched, an IllegalArgumentException will be thrown. (let [hint-var# (first spec) types# (second spec)] (if (seq types#) (let [type# (first types#)] `(let [~hint-var# (tawny.util/tag-symbol ~type# ~hint-var#)] (if (instance? ~type# ~hint-var#) ~@body (with-types [~hint-var# ~(vec (rest types#))] ~@body `(throw (IllegalArgumentException. No types have been matched) Which works nicely and seems to compile down to code without reflection. Thanks again! 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: [ANN] introduction to opencv development with clojure
On Dec 12, 2013, at 4:01 AM, Colin Fleming colin.mailingl...@gmail.com wrote: Seesaw is the gold standard with lib wrapping IMO, it's a fantastic piece of work. thanks. I'll start to study it today and try to grab idea from there. if anyone have any suggestion on best-practices to wrap an OO c++/java lib which has such an amount of mutable objects like OpenCV has, I'll be very thankful. Mimmo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ClojureScript] [ANN] A post on CLJS DOM manipulation libraries
Informative, nice work Dave! Perhaps a small mistake: looks like you're using `dommy/text` in your jayq example. On 12 December 2013 07:05, Dave Della Costa ddellaco...@gmail.com wrote: Hi folks, Albeit a little later than I'd hoped, I've written a post giving a high-level overview of the DOM manipulation/Event handling libraries available in ClojureScript at the present time: http://davedellacosta.com/cljs-dom-survey It's aimed at beginners in ClojureScript, for the most part, but may be useful to anyone who isn't familiar with the DOM libraries out there and their relative merits. If I've forgotten anything or made any mistakes, or otherwise have comments, please drop me a line. Thank you! Best, Dave -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- -- You 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: Should I be using deftype, gen-class or defrecord instead of this hack?
It's hard to offer an opinion without some sense of the data structures you
are producing.
In the case of sorting by identifier, why do you need a new type? It sounds
like you're basing your logic on data types, rather than the data itself.
- James
On 12 December 2013 04:26, Tim tcr1...@gmail.com wrote:
As an experiment, I've written a DSL that generates database queries using
*effectively* only the data. The query logic is derived from the data
assemblance and choice of data structures (or types). I am at the stage
where I have all the logic working, and I am now moving into perf testing
and tuning. BUT, before I do, there's this one hack I have implemented that
has me asking the this question.
As I wrote the DSL I ran out of data structure types to account for a few
defined meanings within the query logic. As a short term hack I decided to
attach meta data to symbols where the meta data contained a data value
along with, for example, a sort option. I only intended for this to be
short term until I got around to figuring out the semantics of Clojure's
deftype or defrecord.
Here's the hack:
(defn object [v m]
(let [id (gensym #object#)]
(with-meta id
(merge m {:default v :id id}
(defn object? [o]
(if-let [it (meta o)]
(if (= (it :id) o)
true false)
false))
(defn inspect
([o]
(inspect o nil))
([o xs]
(if-let [it (meta o)]
(if (= (:id it) o)
(if-let [x (first xs)]
(if (coll? x)
(select-keys it x)
(x it))
it)
(defn instance
([o]
(instance o nil))
([o args]
(if-let [it (meta o)]
(if (= (:id it) o)
(if-let [x (:default it)]
(if (fn? x)
(if-let [args (or (and (some identity args) args) (it
:args))]
(apply x args)
(x))
x)
it)
= (def o (object #(java.util.UUID/randomUUID){:sort '})
object#24397
= (object? o))
true
= (instance o)
#uuid 3c9cca8b-59e2-46b2-9175-468de3a21a22
= (inspect o :sort))
So now I've been reading up on Clojure's deftypes defrecords and while
it I expect they are both considered the right tool for the job,
everything I read seems like overly complicated bloat code compared to my
hack. Am I missing something? Is this a case where you wouldn't be caught
dead using the above hack? Why or why not?
As I see it: I'm not creating and/or holding millions of objects that
would need to be shared, altered or held onto. These have relatively short
lives that only serve in compiling to a different query language. Type
hints or java interop really shouldn't matter.
Notes:
1. While the above function names may carry OO concepts, these functions
are not intended to fulfil all of them them; rather they only fill a
specific functionality gap that appears to meet my needs.
2. I realize one wouldn't sort on a UUID, it's just an example to show the
functionality. :)
Thanks,
Tim
--
--
You 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] [ANN] A post on CLJS DOM manipulation libraries
Most definitely a mistake--good catch Luke! I've updated it with something jayq-specific. Thank you! DD (2013/12/12 19:52), Luke Morton wrote: Informative, nice work Dave! Perhaps a small mistake: looks like you're using `dommy/text` in your jayq example. On 12 December 2013 07:05, Dave Della Costa ddellaco...@gmail.com mailto:ddellaco...@gmail.com wrote: Hi folks, Albeit a little later than I'd hoped, I've written a post giving a high-level overview of the DOM manipulation/Event handling libraries available in ClojureScript at the present time: http://davedellacosta.com/cljs-dom-survey It's aimed at beginners in ClojureScript, for the most part, but may be useful to anyone who isn't familiar with the DOM libraries out there and their relative merits. If I've forgotten anything or made any mistakes, or otherwise have comments, please drop me a line. Thank you! Best, Dave -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com mailto:clojurescript%2bunsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com mailto:clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- -- You 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] A post on CLJS DOM manipulation libraries
I seem to be getting a 404 on the link now. -- -- You 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: [ANN] A post on CLJS DOM manipulation libraries
Apologies...I messed something up temporarily fixing the issue Luke Morton found. Is it still broken for you? (2013/12/12 22:33), Creighton Kirkendall wrote: I seem to be getting a 404 on the link now. -- -- You 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: Should I be using deftype, gen-class or defrecord instead of this hack?
Hi James,
I'm not basing logic on types alone. That aside, here's an example to
highlight the specific problem:
{:where [:id 'identity]}
Here are two options for sorting by id:
1. {:where [:id 'identity] :sort-by :id :sort '}
2. {:where [:id (object 'identity {:sort })}
I chose #2, which is immensely helpful when constructing multi-sort
queries. I can understand how #2 may raise some eyebrows/questions from a
query logic perspective, but I am trying to reduce the scope down to
question at hand and not get into unraveling the entire spec.
Does that help? Thanks.
On Thursday, December 12, 2013 7:59:26 AM UTC-5, James Reeves wrote:
It's hard to offer an opinion without some sense of the data structures
you are producing.
In the case of sorting by identifier, why do you need a new type? It
sounds like you're basing your logic on data types, rather than the data
itself.
- James
On 12 December 2013 04:26, Tim tcr...@gmail.com javascript: wrote:
As an experiment, I've written a DSL that generates database queries
using *effectively* only the data. The query logic is derived from the data
assemblance and choice of data structures (or types). I am at the stage
where I have all the logic working, and I am now moving into perf testing
and tuning. BUT, before I do, there's this one hack I have implemented that
has me asking the this question.
As I wrote the DSL I ran out of data structure types to account for a few
defined meanings within the query logic. As a short term hack I decided to
attach meta data to symbols where the meta data contained a data value
along with, for example, a sort option. I only intended for this to be
short term until I got around to figuring out the semantics of Clojure's
deftype or defrecord.
Here's the hack:
(defn object [v m]
(let [id (gensym #object#)]
(with-meta id
(merge m {:default v :id id}
(defn object? [o]
(if-let [it (meta o)]
(if (= (it :id) o)
true false)
false))
(defn inspect
([o]
(inspect o nil))
([o xs]
(if-let [it (meta o)]
(if (= (:id it) o)
(if-let [x (first xs)]
(if (coll? x)
(select-keys it x)
(x it))
it)
(defn instance
([o]
(instance o nil))
([o args]
(if-let [it (meta o)]
(if (= (:id it) o)
(if-let [x (:default it)]
(if (fn? x)
(if-let [args (or (and (some identity args) args) (it
:args))]
(apply x args)
(x))
x)
it)
= (def o (object #(java.util.UUID/randomUUID){:sort '})
object#24397
= (object? o))
true
= (instance o)
#uuid 3c9cca8b-59e2-46b2-9175-468de3a21a22
= (inspect o :sort))
So now I've been reading up on Clojure's deftypes defrecords and while
it I expect they are both considered the right tool for the job,
everything I read seems like overly complicated bloat code compared to my
hack. Am I missing something? Is this a case where you wouldn't be caught
dead using the above hack? Why or why not?
As I see it: I'm not creating and/or holding millions of objects that
would need to be shared, altered or held onto. These have relatively short
lives that only serve in compiling to a different query language. Type
hints or java interop really shouldn't matter.
Notes:
1. While the above function names may carry OO concepts, these functions
are not intended to fulfil all of them them; rather they only fill a
specific functionality gap that appears to meet my needs.
2. I realize one wouldn't sort on a UUID, it's just an example to show
the functionality. :)
Thanks,
Tim
--
--
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
Re: [ClojureScript] Re: [ANN] A post on CLJS DOM manipulation libraries
Nice job!
I noticed a few small things on the Enfocus section that I would tweak but
nothing that really makes all that big a difference. I listed a few below.
You don't need to reference js/document when doing a single selector and you
don't need the [] around the selector.
(ef/at js/document [#menu ul] (ef/append li))
is equivalent to
(ef/at #menu ul (ef/append li))
Enfocus is generally about chaining transforms and your add listener could be
seen as a custom transform. With this in mind, I might recommend something
closer to this.
(defn add-annoying-alert-listener_enfocus! []
(ef-events/listen
:click
(fn [evt]
(let [atxt (- evt (.-currentTarget) (.-text))
msg (str You clicked atxt)]
(.alert js/window msg)
(.preventDefault evt)
(defn add-menu-link_enfocus!
[link]
(let [link-str (- link first name capitalize)
href (last link)
li (ef/html [:li [:a {:href href} link-str]])]
(ef/at
#menu ul (ef/append li)
(str a[href= href ]) (add-annoying-alert-listener_enfocus!
CK
On Thursday, December 12, 2013 8:34:53 AM UTC-5, David Della Costa wrote:
Apologies...I messed something up temporarily fixing the issue Luke
Morton found. Is it still broken for you?
(2013/12/12 22:33), Creighton Kirkendall wrote:
I seem to be getting a 404 on the link now.
--
--
You 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: [ANN] A post on CLJS DOM manipulation libraries
Creighton, this is really excellent feedback and exactly what I was
hoping for. I am relatively new to Enfocus and had a feeling I could
have written that code in a more idiomatic way. I'll edit the piece to
incorporate your suggestions ASAP.
Many thanks!
DD
(2013/12/12 23:00), Creighton Kirkendall wrote:
Nice job!
I noticed a few small things on the Enfocus section that I would tweak but
nothing that really makes all that big a difference. I listed a few below.
You don't need to reference js/document when doing a single selector and you
don't need the [] around the selector.
(ef/at js/document [#menu ul] (ef/append li))
is equivalent to
(ef/at #menu ul (ef/append li))
Enfocus is generally about chaining transforms and your add listener could be
seen as a custom transform. With this in mind, I might recommend something
closer to this.
(defn add-annoying-alert-listener_enfocus! []
(ef-events/listen
:click
(fn [evt]
(let [atxt (- evt (.-currentTarget) (.-text))
msg (str You clicked atxt)]
(.alert js/window msg)
(.preventDefault evt)
(defn add-menu-link_enfocus!
[link]
(let [link-str (- link first name capitalize)
href (last link)
li (ef/html [:li [:a {:href href} link-str]])]
(ef/at
#menu ul (ef/append li)
(str a[href= href ]) (add-annoying-alert-listener_enfocus!
CK
On Thursday, December 12, 2013 8:34:53 AM UTC-5, David Della Costa wrote:
Apologies...I messed something up temporarily fixing the issue Luke
Morton found. Is it still broken for you?
(2013/12/12 22:33), Creighton Kirkendall wrote:
I seem to be getting a 404 on the link now.
--
--
You 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: Should I be using deftype, gen-class or defrecord instead of this hack?
Why not something like:
{:where [[:id 'identity]] :sort [[:id :desc]]}
That would make it relatively straightforward to merge queries (use `into`
and then check for duplicates in :sort).
To me, it doesn't make a huge amount of sense to tie sorting logic onto the
field itself.
- James
On 12 December 2013 13:56, Tim tcr1...@gmail.com wrote:
Hi James,
I'm not basing logic on types alone. That aside, here's an example to
highlight the specific problem:
{:where [:id 'identity]}
Here are two options for sorting by id:
1. {:where [:id 'identity] :sort-by :id :sort '}
2. {:where [:id (object 'identity {:sort })}
I chose #2, which is immensely helpful when constructing multi-sort
queries. I can understand how #2 may raise some eyebrows/questions from a
query logic perspective, but I am trying to reduce the scope down to
question at hand and not get into unraveling the entire spec.
Does that help? Thanks.
On Thursday, December 12, 2013 7:59:26 AM UTC-5, James Reeves wrote:
It's hard to offer an opinion without some sense of the data structures
you are producing.
In the case of sorting by identifier, why do you need a new type? It
sounds like you're basing your logic on data types, rather than the data
itself.
- James
On 12 December 2013 04:26, Tim tcr...@gmail.com wrote:
As an experiment, I've written a DSL that generates database queries
using *effectively* only the data. The query logic is derived from the data
assemblance and choice of data structures (or types). I am at the stage
where I have all the logic working, and I am now moving into perf testing
and tuning. BUT, before I do, there's this one hack I have implemented that
has me asking the this question.
As I wrote the DSL I ran out of data structure types to account for a
few defined meanings within the query logic. As a short term hack I decided
to attach meta data to symbols where the meta data contained a data value
along with, for example, a sort option. I only intended for this to be
short term until I got around to figuring out the semantics of Clojure's
deftype or defrecord.
Here's the hack:
(defn object [v m]
(let [id (gensym #object#)]
(with-meta id
(merge m {:default v :id id}
(defn object? [o]
(if-let [it (meta o)]
(if (= (it :id) o)
true false)
false))
(defn inspect
([o]
(inspect o nil))
([o xs]
(if-let [it (meta o)]
(if (= (:id it) o)
(if-let [x (first xs)]
(if (coll? x)
(select-keys it x)
(x it))
it)
(defn instance
([o]
(instance o nil))
([o args]
(if-let [it (meta o)]
(if (= (:id it) o)
(if-let [x (:default it)]
(if (fn? x)
(if-let [args (or (and (some identity args) args) (it
:args))]
(apply x args)
(x))
x)
it)
= (def o (object #(java.util.UUID/randomUUID){:sort '})
object#24397
= (object? o))
true
= (instance o)
#uuid 3c9cca8b-59e2-46b2-9175-468de3a21a22
= (inspect o :sort))
So now I've been reading up on Clojure's deftypes defrecords and while
it I expect they are both considered the right tool for the job,
everything I read seems like overly complicated bloat code compared to
my hack. Am I missing something? Is this a case where you wouldn't be
caught dead using the above hack? Why or why not?
As I see it: I'm not creating and/or holding millions of objects that
would need to be shared, altered or held onto. These have relatively short
lives that only serve in compiling to a different query language. Type
hints or java interop really shouldn't matter.
Notes:
1. While the above function names may carry OO concepts, these functions
are not intended to fulfil all of them them; rather they only fill a
specific functionality gap that appears to meet my needs.
2. I realize one wouldn't sort on a UUID, it's just an example to show
the functionality. :)
Thanks,
Tim
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
Re: cider status
On Tuesday, November 12, 2013 5:10:43 PM UTC+2, John Hume wrote: The last (non-authoritative) word on cider on this mailing list[1] was that it is unstable. Is that really the case? Is it just a matter of many packages that depend on it not being updated? I'm cider's primary maintainer. My opinion is that it's very stable at the moment. More stable and less buggy than nrepl.el ever was. Most packages that used to depend on nrepl.el, now depend on cider. nrepl-ritz is only notable exception. I tried checking the official mailing list[2] and was surprised to find that it's private. That was an accidental mistake (it seems google groups are private by default). I'm trying to understand this because I submitted a recipe to MELPA, and they will no longer accept packages that depend on nrepl.el. Thanks. -hume. [1] https://groups.google.com/forum/#!searchin/clojure/cider/clojure/JfS7ZzePtA4/ZAPHHn1zS5gJ Tim Visher: Also, Cider is _unstable_ at this point. I'm still using nrepl 0.2.0 and it's working fine. I would _not_ recommend upgrading to Cider at this point. [2] https://groups.google.com/forum/#!forum/cider-emacs -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: cider status
On Wednesday, November 13, 2013 1:50:32 AM UTC+2, Tim Visher wrote: While I'm glad to hear that there are users out there for whom cider is working great, I would still say based on following the project on GitHub that there are far too many issues being filed based on function names not being defined etc. to consider the current release stable. I'm fairly certain that those problems are behind us now. As always, YMMV. On Tue, Nov 12, 2013 at 12:37 PM, Gary Trakhman gary.t...@gmail.comjavascript: wrote: Stable for me, the only outside tool I use that relies on it is ac-nrepl, but switching the hooks over for cider was painless. On Tue, Nov 12, 2013 at 12:35 PM, Norman Richards o...@nostacktrace.comjavascript: wrote: On Tue, Nov 12, 2013 at 10:22 AM, Phillip Lord philli...@newcastle.ac.uk javascript: wrote: 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. Although I don't understand why anyone thought it was a good idea to change package names, I can confirm that for my daily clojure development, the transition was fairly painless (uninstall/reinstall packages and update some init.el configuration) and has not caused any problems with the set of emacs clojure tools I use. (which does not include ritz) I don't remember when I made the move, but it's been at least a week. -- -- 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 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.
Re: cider status
On Tuesday, November 19, 2013 4:56:05 PM UTC+2, 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. Marmalade is a huge problem these days - frequent outages, not to mention many package uploads (including cider 0.4) got corrupted and Nic hasn't been able to figure out what's going on there. I'd suggest to everyone to use MELPA for the time being. 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: Should I be using deftype, gen-class or defrecord instead of this hack?
And that's ok, there's obviously more to it and not knowing or
understanding the spec I wouldn't expect you to make sense of that piece.
Still, the question really is: If you were to do this, would you implement
deftype, gen-class instead? Would the hacked approach be a bad idea and if
so for what reason? Staying within the bounds of the question are there
other approaches to doing the same thing? I initially just wanted to use
with-meta that could attach to any data, but obviously with-meta limits
what it can be attached to which led to the above approach.
Thanks,
On Thursday, December 12, 2013 10:43:22 AM UTC-5, James Reeves wrote:
Why not something like:
{:where [[:id 'identity]] :sort [[:id :desc]]}
That would make it relatively straightforward to merge queries (use `into`
and then check for duplicates in :sort).
To me, it doesn't make a huge amount of sense to tie sorting logic onto
the field itself.
- James
On 12 December 2013 13:56, Tim tcr...@gmail.com javascript: wrote:
Hi James,
I'm not basing logic on types alone. That aside, here's an example to
highlight the specific problem:
{:where [:id 'identity]}
Here are two options for sorting by id:
1. {:where [:id 'identity] :sort-by :id :sort '}
2. {:where [:id (object 'identity {:sort })}
I chose #2, which is immensely helpful when constructing multi-sort
queries. I can understand how #2 may raise some eyebrows/questions from a
query logic perspective, but I am trying to reduce the scope down to
question at hand and not get into unraveling the entire spec.
Does that help? Thanks.
On Thursday, December 12, 2013 7:59:26 AM UTC-5, James Reeves wrote:
It's hard to offer an opinion without some sense of the data structures
you are producing.
In the case of sorting by identifier, why do you need a new type? It
sounds like you're basing your logic on data types, rather than the data
itself.
- James
On 12 December 2013 04:26, Tim tcr...@gmail.com wrote:
As an experiment, I've written a DSL that generates database queries
using *effectively* only the data. The query logic is derived from the
data
assemblance and choice of data structures (or types). I am at the stage
where I have all the logic working, and I am now moving into perf testing
and tuning. BUT, before I do, there's this one hack I have implemented
that
has me asking the this question.
As I wrote the DSL I ran out of data structure types to account for a
few defined meanings within the query logic. As a short term hack I
decided
to attach meta data to symbols where the meta data contained a data value
along with, for example, a sort option. I only intended for this to be
short term until I got around to figuring out the semantics of Clojure's
deftype or defrecord.
Here's the hack:
(defn object [v m]
(let [id (gensym #object#)]
(with-meta id
(merge m {:default v :id id}
(defn object? [o]
(if-let [it (meta o)]
(if (= (it :id) o)
true false)
false))
(defn inspect
([o]
(inspect o nil))
([o xs]
(if-let [it (meta o)]
(if (= (:id it) o)
(if-let [x (first xs)]
(if (coll? x)
(select-keys it x)
(x it))
it)
(defn instance
([o]
(instance o nil))
([o args]
(if-let [it (meta o)]
(if (= (:id it) o)
(if-let [x (:default it)]
(if (fn? x)
(if-let [args (or (and (some identity args) args) (it
:args))]
(apply x args)
(x))
x)
it)
= (def o (object #(java.util.UUID/randomUUID){:sort '})
object#24397
= (object? o))
true
= (instance o)
#uuid 3c9cca8b-59e2-46b2-9175-468de3a21a22
= (inspect o :sort))
So now I've been reading up on Clojure's deftypes defrecords and
while it I expect they are both considered the right tool for the job,
everything I read seems like overly complicated bloat code compared to
my hack. Am I missing something? Is this a case where you wouldn't be
caught dead using the above hack? Why or why not?
As I see it: I'm not creating and/or holding millions of objects that
would need to be shared, altered or held onto. These have relatively short
lives that only serve in compiling to a different query language. Type
hints or java interop really shouldn't matter.
Notes:
1. While the above function names may carry OO concepts, these
functions are not intended to fulfil all of them them; rather they only
fill a specific functionality gap that appears to meet my needs.
2. I realize one wouldn't sort on a UUID, it's just an example to show
the functionality. :)
Thanks,
Tim
--
--
You received this message because you are subscribed to the Google
Groups
[ANN] Munich Lambda Meetups
Hi everyone, We (Munich Lambda[1]) are organising Meetups, dedicated to Functional Programming, and Clojure specifically. Even though we already know many people who're doing Clojure here in Munich and area, we believe that there're more enthusiasts that we haven't yet met, who may be interested to meet and talk about Clojure and other FP languages. During the past year we've organised 4 Clojure Workshops [2], and many User Groups where people gave talks on Clojure and related tech. You can find all the information on past and upcoming events here: http://www.meetup.com/Munich-Lambda/ We also announce all the meetups on our Twitter account: https://twitter.com/defworkshop If you know someone from Munich and area, let them know about the initiative. We have big plans on making Clojure community stronger here, making more workshops and trainings, helping people to start using Clojure in production and for fun, and we'd love to meet new people. Thanks! [1] http://www.meetup.com/Munich-Lambda/ [2] http://clojureworkshop.com -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN Elastisch 1.3.0 is released
Elastisch [1] is a minimalistic feature complete Clojure client for ElasticSearch. 1.3.0 is a minor feature and usability release. Release notes: http://blog.clojurewerkz.org/blog/2013/12/12/elastisch-1-dot-3-0-is-released/ 1. http://clojureelasticsearch.info -- 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.
ANN Neocons 2.0.1 is released
Neocons [1] is a Clojure client for Neo4J REST API. 2.0.1 fixes one compatibility issue with Neo4J 2.0 GA. Release notes: http://blog.clojurewerkz.org/blog/2013/12/12/neocons-2-dot-0-1-is-released/ 1. http://clojureneo4j.info -- 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.
Re: Should I be using deftype, gen-class or defrecord instead of this hack?
gen-class is really there just for compatibility with Java. deftype should
be preferred.
Here's a project of mine where I create a custom type and data reader, if
you want an example: https://github.com/weavejester/crumpets
However, it feels like you're looking for a solution in the wrong place. I
obviously don't know the precise problem you're trying to solve, so I may
be completely wrong, but the example code you've shown so far seems a
little odd.
- James
On 12 December 2013 16:34, Tim tcr1...@gmail.com wrote:
And that's ok, there's obviously more to it and not knowing or
understanding the spec I wouldn't expect you to make sense of that piece.
Still, the question really is: If you were to do this, would you implement
deftype, gen-class instead? Would the hacked approach be a bad idea and if
so for what reason? Staying within the bounds of the question are there
other approaches to doing the same thing? I initially just wanted to use
with-meta that could attach to any data, but obviously with-meta limits
what it can be attached to which led to the above approach.
Thanks,
On Thursday, December 12, 2013 10:43:22 AM UTC-5, James Reeves wrote:
Why not something like:
{:where [[:id 'identity]] :sort [[:id :desc]]}
That would make it relatively straightforward to merge queries (use
`into` and then check for duplicates in :sort).
To me, it doesn't make a huge amount of sense to tie sorting logic onto
the field itself.
- James
On 12 December 2013 13:56, Tim tcr...@gmail.com wrote:
Hi James,
I'm not basing logic on types alone. That aside, here's an example to
highlight the specific problem:
{:where [:id 'identity]}
Here are two options for sorting by id:
1. {:where [:id 'identity] :sort-by :id :sort '}
2. {:where [:id (object 'identity {:sort })}
I chose #2, which is immensely helpful when constructing multi-sort
queries. I can understand how #2 may raise some eyebrows/questions from a
query logic perspective, but I am trying to reduce the scope down to
question at hand and not get into unraveling the entire spec.
Does that help? Thanks.
On Thursday, December 12, 2013 7:59:26 AM UTC-5, James Reeves wrote:
It's hard to offer an opinion without some sense of the data structures
you are producing.
In the case of sorting by identifier, why do you need a new type? It
sounds like you're basing your logic on data types, rather than the data
itself.
- James
On 12 December 2013 04:26, Tim tcr...@gmail.com wrote:
As an experiment, I've written a DSL that generates database queries
using *effectively* only the data. The query logic is derived from the
data
assemblance and choice of data structures (or types). I am at the stage
where I have all the logic working, and I am now moving into perf testing
and tuning. BUT, before I do, there's this one hack I have implemented
that
has me asking the this question.
As I wrote the DSL I ran out of data structure types to account for a
few defined meanings within the query logic. As a short term hack I
decided
to attach meta data to symbols where the meta data contained a data value
along with, for example, a sort option. I only intended for this to be
short term until I got around to figuring out the semantics of Clojure's
deftype or defrecord.
Here's the hack:
(defn object [v m]
(let [id (gensym #object#)]
(with-meta id
(merge m {:default v :id id}
(defn object? [o]
(if-let [it (meta o)]
(if (= (it :id) o)
true false)
false))
(defn inspect
([o]
(inspect o nil))
([o xs]
(if-let [it (meta o)]
(if (= (:id it) o)
(if-let [x (first xs)]
(if (coll? x)
(select-keys it x)
(x it))
it)
(defn instance
([o]
(instance o nil))
([o args]
(if-let [it (meta o)]
(if (= (:id it) o)
(if-let [x (:default it)]
(if (fn? x)
(if-let [args (or (and (some identity args) args) (it
:args))]
(apply x args)
(x))
x)
it)
= (def o (object #(java.util.UUID/randomUUID){:sort '})
object#24397
= (object? o))
true
= (instance o)
#uuid 3c9cca8b-59e2-46b2-9175-468de3a21a22
= (inspect o :sort))
So now I've been reading up on Clojure's deftypes defrecords and
while it I expect they are both considered the right tool for the job,
everything I read seems like overly complicated bloat code compared to
my hack. Am I missing something? Is this a case where you wouldn't be
caught dead using the above hack? Why or why not?
As I see it: I'm not creating and/or holding millions of objects that
would need to be shared, altered or held onto. These have relatively short
lives that only serve in compiling to a different query language. Type
hints or java
Re: Bitwise Operations in core.logic?
There is actually a out of the box way to do this - but it's not through the core.logic. What you want to do is to use the java_interlop to import and use http://commons.apache.org/proper/commons-net/apidocs/org/apache/commons/net/util/SubnetUtils.html On Monday, 24 June 2013 12:01:40 UTC-4, David Rocamora wrote: Hi, I've been exploring core.logic while working through The Reasoned Schemer and would like to be able to describe relationships between IP addresses and networks that they may or may not be a part of. It's straightforward to do this in Clojure because I can use bit-and on a network and a mask and on an IP and a mask. If the results are the same, then the IP is in the network. At least, that is how I understand it. Here's a predicate function that does this: (defn in-network? [address network netmask] (= (map bit-and network netmask) (map bit-and address netmask))) ;; 192.168.1.3 is in 192.168.1.0/24 (in-network? [192 168 1 3] [192 168 1 0] [255 255 255 0]) ;; true ;; but 192.168.100.3 isn't (in-network? [192 168 100 3] [192 168 1 0] [255 255 255 0]) ;; false It would be cool to be able to do this with core.logic so I could have a relationship like in-networko that could describe IPs and networks. I'm running into issues implementing this because lvars aren't supported by the bitwise operators from Clojure and I can't seem to find anything in core.logic that does what I need out of the box. The Reasoned Schemer describes a bunch of bitwise operations, but implementing them seems like it will involve a lot of work to turn the integers from an IP into lists of bits and back again. Is there a better way to do this? Any insight would be appreciated. Thanks in advance, 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: Should I be using deftype, gen-class or defrecord instead of this hack?
Thanks for the responses. I took a look at your project and found it to be more useful than any documentation I've seen on deftype, so thanks for linking to it. Tim On Thursday, December 12, 2013 2:20:21 PM UTC-5, James Reeves wrote: gen-class is really there just for compatibility with Java. deftype should be preferred. Here's a project of mine where I create a custom type and data reader, if you want an example: https://github.com/weavejester/crumpetshttps://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fweavejester%2Fcrumpetssa=Dsntz=1usg=AFQjCNFAbFSPOo7A60iH9ecMtaG1asRquw However, it feels like you're looking for a solution in the wrong place. I obviously don't know the precise problem you're trying to solve, so I may be completely wrong, but the example code you've shown so far seems a little odd. - James -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to 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] - jMonkeyEngine3 game dev for Clojure
As far as I know, I've created the first lein template that allows you to run jMonkeyEngine3 from Clojure without any configuration. Create a projectlein new jme3 project-name-here Download depscd project-name-here; lein deps Run the demolein run Game Engine: http://jmonkeyengine.org/Github: https://github.com/runexec/clj-jme3 -- -- You 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] - jMonkeyEngine3 game dev for Clojure
Nice, I tried it but got the following error under OS X: Exception in thread LWJGL Renderer Thread java.lang.UnsatisfiedLinkError: Can't load library: /.../jme-test/liblwjgl.dylib I see that it's under /.../jme-test/target/native/macosx On Thu, Dec 12, 2013 at 3:40 PM, Kelker Ryan theinter...@yandex.com wrote: As far as I know, I've created the first lein template that allows you to run jMonkeyEngine3 from Clojure without any configuration. *Create a project* lein new jme3 project-name-here *Download deps* cd project-name-here; lein deps *Run the demo* lein run Game Engine:* http://jmonkeyengine.org/ http://jmonkeyengine.org/* Github: *https://github.com/runexec/clj-jme3*http://%20https://github.com/runexec/clj-jme3 -- -- You 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] A post on CLJS DOM manipulation libraries
Hi Dave, Thanks for the overview. I found one error. When running the Google Clojure example on its own this expression gives an error: (first (query #menu ul)) This is because 'first' depends on the protocols implemented in domina.events. This expression will fix the error: (aget (query #menu ul) 0) On Thursday, December 12, 2013 8:05:57 AM UTC+1, David Della Costa wrote: Hi folks, Albeit a little later than I'd hoped, I've written a post giving a high-level overview of the DOM manipulation/Event handling libraries available in ClojureScript at the present time: http://davedellacosta.com/cljs-dom-survey It's aimed at beginners in ClojureScript, for the most part, but may be useful to anyone who isn't familiar with the DOM libraries out there and their relative merits. If I've forgotten anything or made any mistakes, or otherwise have comments, please drop me a line. Thank you! Best, 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: [ANN] introduction to opencv development with clojure
There was talk a while ago about splitting out some of the generally useful parts of Seesaw into separate libs, particularly the object config part would be very useful, I think. I don't think anything ever came of it, though. On 12 December 2013 23:34, Mimmo Cosenza mimmo.cose...@gmail.com wrote: On Dec 12, 2013, at 4:01 AM, Colin Fleming colin.mailingl...@gmail.com wrote: Seesaw is the gold standard with lib wrapping IMO, it's a fantastic piece of work. thanks. I'll start to study it today and try to grab idea from there. if anyone have any suggestion on best-practices to wrap an OO c++/java lib which has such an amount of mutable objects like OpenCV has, I'll be very thankful. Mimmo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
map vs map in core.async
Dear list, I'm playing around with core.async and I don't understand the following. 1) I make a source channel that emits a random number every second. (def continue (atom true)) (def source (let [out (as/chan)] (as/go-loop [] (when @continue (as/put! out (rand-int 10)) (as/! (as/timeout 1000)) (recur))) out)) 2) I make a sink channel that simply discards whatever it gets: (def sink (let [in (as/chan)] (as/go-loop [] (let [v (as/! in)] (when-not (nil? v) (recur in)) 3) Now I pipe the source channel to the sink channel after mapping a print function over both of them: (as/pipe (as/map (fn [x] (print ) x) source) (as/map (fn [x] (print ) x) sink)) I expected to see a sequence of the form However, only one or very few get printed, so I get a sequence Why? Furthermore, is what I am doing idiomatic or am I approaching things in the wrong way? All feedback appreciated! -- -- You 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: [ANN] A post on CLJS DOM manipulation libraries
Hi Creighton, I've updated the post with a bit expanding on the Enfocus
section, including your suggestions.
Thanks again for your great feedback--
DD
(2013/12/12 23:00), Creighton Kirkendall wrote:
Nice job!
I noticed a few small things on the Enfocus section that I would tweak but
nothing that really makes all that big a difference. I listed a few below.
You don't need to reference js/document when doing a single selector and you
don't need the [] around the selector.
(ef/at js/document [#menu ul] (ef/append li))
is equivalent to
(ef/at #menu ul (ef/append li))
Enfocus is generally about chaining transforms and your add listener could be
seen as a custom transform. With this in mind, I might recommend something
closer to this.
(defn add-annoying-alert-listener_enfocus! []
(ef-events/listen
:click
(fn [evt]
(let [atxt (- evt (.-currentTarget) (.-text))
msg (str You clicked atxt)]
(.alert js/window msg)
(.preventDefault evt)
(defn add-menu-link_enfocus!
[link]
(let [link-str (- link first name capitalize)
href (last link)
li (ef/html [:li [:a {:href href} link-str]])]
(ef/at
#menu ul (ef/append li)
(str a[href= href ]) (add-annoying-alert-listener_enfocus!
CK
On Thursday, December 12, 2013 8:34:53 AM UTC-5, David Della Costa wrote:
Apologies...I messed something up temporarily fixing the issue Luke
Morton found. Is it still broken for you?
(2013/12/12 22:33), Creighton Kirkendall wrote:
I seem to be getting a 404 on the link now.
--
--
You 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] A post on CLJS DOM manipulation libraries
Hi Walter, thanks very much for the fix, good catch--I've updated the github repo and the post to reflect this change. Thanks! DD (2013/12/13 6:26), Walter van der Laan wrote: Hi Dave, Thanks for the overview. I found one error. When running the Google Clojure example on its own this expression gives an error: (first (query #menu ul)) This is because 'first' depends on the protocols implemented in domina.events. This expression will fix the error: (aget (query #menu ul) 0) On Thursday, December 12, 2013 8:05:57 AM UTC+1, David Della Costa wrote: Hi folks, Albeit a little later than I'd hoped, I've written a post giving a high-level overview of the DOM manipulation/Event handling libraries available in ClojureScript at the present time: http://davedellacosta.com/cljs-dom-survey http://davedellacosta.com/cljs-dom-survey It's aimed at beginners in ClojureScript, for the most part, but may be useful to anyone who isn't familiar with the DOM libraries out there and their relative merits. If I've forgotten anything or made any mistakes, or otherwise have comments, please drop me a line. Thank you! Best, 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. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: map vs map in core.async
On Thu, Dec 12, 2013 at 06:08:11PM -0800, Joachim De Beule wrote: I expected to see a sequence of the form However, only one or very few get printed, so I get a sequence Why? They're getting buffered. Try this: (as/pipe (as/map (fn [x] (print ) (flush) x) source) (as/map (fn [x] (print ) (flush) x) sink)) Those calls to flush will make sure it prints those characters immediately. Then you'll see the output you're expecting. I can't help you with whether this is the right way to do things, unfortunately, as I've only had very limited experience with core.async. -- -- You 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] - jMonkeyEngine3 game dev for Clojure
I'm sorry to hear that. I run Arch tux x86_64, but I've looked around for some possible OSX solutions and it looks like there's a known issue with liblwjgl and Java 7 on Macs. Here are some things you might want to look into. Fixing LWJGL Java 7 Mac - https://www.youtube.com/watch?v=03R7CZoSa0A LWJGL on OSX with Java 7 - https://wiki.spout.org/LWJGL#Mac_OS_X_and_Java_7 lwjgl on osx/java7 - http://www.java-gaming.org/index.php?topic=27748.0 13.12.2013, 05:56, David Nolen dnolen.li...@gmail.com: Nice, I tried it but got the following error under OS X: Exception in thread LWJGL Renderer Thread java.lang.UnsatisfiedLinkError: Can't load library: /.../jme-test/liblwjgl.dylib I see that it's under /.../jme-test/target/native/macosx On Thu, Dec 12, 2013 at 3:40 PM, Kelker Ryan theinter...@yandex.com wrote: As far as I know, I've created the first lein template that allows you to run jMonkeyEngine3 from Clojure without any configuration. Create a project lein new jme3 project-name-here Download deps cd project-name-here; lein deps Run the demo lein run Game Engine: http://jmonkeyengine.org/ Github: https://github.com/runexec/clj-jme3 -- -- You 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: cider status
Is cider just a new release of nrepl.el or a different thing entirely? Sorry to be a noob, but this is awfully confusing to the uninitiated. -- -- You 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.
