Re: cider status

[Adrian Mowat]

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.

Re: [ANN] - jMonkeyEngine3 game dev for Clojure

[Kelker Ryan]

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" :
> 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  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 
>>
>> Download deps
>>
>> cd ; 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: map> vs map< in core.async

[Carlo Zancanaro]

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: [ClojureScript] Re: [ANN] A post on CLJS DOM manipulation libraries

[Dave Della Costa]

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

[Dave Della Costa]

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
> 
> 
> 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.

map> vs map< in core.async

[Joachim De Beule]

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/ (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: [ANN] introduction to opencv development with clojure

[Colin Fleming]

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  wrote:

> On Dec 12, 2013, at 4:01 AM, Colin Fleming 
> 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.

Re: [ANN] A post on CLJS DOM manipulation libraries

[Walter van der Laan]

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] - jMonkeyEngine3 game dev for Clojure

[David Nolen]

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  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 
>
> *Download deps*
>
> cd ; 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.

[ANN] - jMonkeyEngine3 game dev for Clojure

[Kelker Ryan]

 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 
Download depscd ; 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: Should I be using deftype, gen-class or defrecord instead of this hack?

[Tim]

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/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
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, 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: Bitwise Operations in core.logic?

[Trang Pham]

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?

[James Reeves]

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  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  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  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 exp

ANN Machine Head 1.0.0-beta5 is released

[Michael Klishin]

Machine Head [1] is a minimalistic Clojure MQTT client.

beta5 is a development milestone release.

Release notes:
http://blog.clojurewerkz.org/blog/2013/12/12/machine-head-1-dot-0-0-beta5-is-released/

1. http://clojuremqtt.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

[Michael Klishin]

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.

ANN Elastisch 1.3.0 is released

[Michael Klishin]

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] Munich Lambda Meetups

[Alex P]

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.

Re: Should I be using deftype, gen-class or defrecord instead of this hack?

[Tim]

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 > 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  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: 

Re: cider status

[Bozhidar Batsov]

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 > 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: cider status

[Bozhidar Batsov]

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 
> > 
> 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 
> > > 
>
> > wrote: 
> >> 
> >> 
> >> On Tue, Nov 12, 2013 at 10:22 AM, Phillip Lord 
> >> > 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.com 
> >> 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 clo...@googlegroups.com 
> > Note that posts from new members are moderated - please be patient with 
> your 
> > first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to clojure+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: cider status

[Bozhidar Batsov]

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: Should I be using deftype, gen-class or defrecord instead of this hack?

[James Reeves]

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  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  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
>

Re: [ClojureScript] Re: [ANN] A post on CLJS DOM manipulation libraries

[Dave Della Costa]

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: [ClojureScript] Re: [ANN] A post on CLJS DOM manipulation libraries

[Creighton Kirkendall]

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?

[Tim]

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 > 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 clojure@googlegroups.com
Note that posts from new members are m

Re: [ClojureScript] Re: [ANN] A post on CLJS DOM manipulation libraries

[Dave Della Costa]

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] [ANN] A post on CLJS DOM manipulation libraries

[Dave Della Costa]

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  > 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.
> 
> 
> -- 
> 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

[Creighton Kirkendall]

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?

[James Reeves]

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  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

[Luke Morton]

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  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: [ANN] introduction to opencv development with clojure

[Mimmo Cosenza]

On Dec 12, 2013, at 4:01 AM, Colin Fleming  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: type hinting overloaded methods

[Phillip Lord]

Phillip Lord  writes:

> Mikera  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.